Fix next_key in table rows response

[poplexity]

antelope-rs/crates/antelope/src/api/v1/chain.rs

Lines 266 to 289 in ccd4422

	match params.lower_bound {
	Some(TableIndexType::NAME(_)) => {
	next_key = Some(TableIndexType::NAME(name!(next_key_str.as_str())));
	}
	Some(TableIndexType::UINT64(_)) => {
	next_key = Some(TableIndexType::UINT64(next_key_str.parse().unwrap()));
	}
	Some(TableIndexType::UINT128(_)) => {
	next_key = Some(TableIndexType::UINT128(next_key_str.parse().unwrap()));
	}
	Some(TableIndexType::CHECKSUM160(_)) => {
	next_key = Some(TableIndexType::CHECKSUM160(
	Checksum160::from_bytes(hex_to_bytes(&next_key_str).as_slice()).unwrap(),
	));
	}
	Some(TableIndexType::CHECKSUM256(_)) => {
	next_key = Some(TableIndexType::CHECKSUM256(
	Checksum256::from_bytes(hex_to_bytes(&next_key_str).as_slice()).unwrap(),
	));
	}
	Some(TableIndexType::FLOAT64(_)) => {
	next_key = Some(TableIndexType::FLOAT64(next_key_str.parse().unwrap()));
	}
	None => {}

When the lower_bound is not specified in the request params, it's None, which means it defaults to the u64 of the primary key. So we should default to treating/parsing next_key as u64.

[poplexity]

As a workaround, we've just set the lower_bound in the initial query params to be TableIndexType::UINT64(0) but this should be fixed properly.