Add next_key to get_table_rows API

[andriantolie]

Change Description

Related to #7313. This PR adds a new field called more2 to the result of get_table_rows chain API. The more2 field contains the key of the next row that wasn't returned in the response in the same format that was expected for the lower_bound and upper_bound fields of the request, i.e.

• without --key-type -> the more2 field will contain uint64_t of the next row primary key;
• --key-type sha256 -> the more2 field will contain sha256 of the next row secondary key
• --key-type float128, the more2 field will contain floating number represented as uint128 of the next row secondary key
• etc...

This PR removes fixed_key.hpp as it's unused anymore and bring in fixed_bytes.hpp from eosio.cdt.

This PR also introduces breaking API changes for the input of get_table_rows for key-type sha256, ripemd160, i256. It also introduces breaking changes in the representation of uint128 in the JSON response (details below).

A new PR is also added in the FC repo EOSIO/fc#111

Consensus Changes

• Consensus Changes

API Changes

• API Changes

This PR changes the input of get_table_rows for the following key-type:

• sha256 -> convert the input to an array of two uint128_t in little endian (which is the same as how fixed_bytes represents the data)
• i256 -> convert the input to an array of two uint128_t in little endian (which is the same as how fixed_bytes represents the data)
• ripemd160 -> convert the input to an array of two uint128_t in little endian (which is the same as how fixed_bytes represents the data)
  And this PR changes the way uint128 being represented in the JSON response, from previously being represented as binary, it is now being represented as a decimal which is easier to be understood by the user.

Documentation Additions

• Documentation Additions

[jafri]

Any consideration on giving it a better name like next_key instead of more2?

[andriantolie]

Any consideration on giving it a better name like next_key instead of more2?
That sounds good, thanks for the input. I've made the change in this PR.

[tbfleming]

The float128_t aliasing problem also occurs in existing consensus-handling code. For now, keep the float128_t handling as is, but fix the other aliasing problems. float128_t fixes can come later: #7960

[andriantolie]

@tbfleming Thanks for the feedback. I've updated my PR to fix the strict alias violation.

[arhag]

Please also update the fc submodule to the latest master that will include the changes in EOSIO/fc#111.

[arhag]

The comment can be reverted because there is no longer a need for a specialization for uint128_t.

[aclark-b1]

Docs team - I don't believe this change ever made it into our documentation. Can you please add it?