Allow struct serialization from array input

[conr2d]

Change Description

eosio::chain::abi_serializer in libchain allows serialization of struct from array, but eosjs only serializes object to struct.

When sending a transaction with transaction_extensions, the abi of transaction in eosjs defines transaction_extensions as extension[], and extension is a struct with two fields, type (uint16) and data (bytes). However, during calling transact(), it calls /v1/chain/get_required_keys RPC, but in libchain, transaction_extensions is defined by std::vector<std::pair<uint16_t,vector<char>>>, so get_required_keys will be aborted, because libchain will fail to convert the parameters in json to eosio::chain::transaction.

At this time, there is no way to send a transaction with transaction extensions by transact() of eosjs-api. This PR will provide a way to serialize structs from array in the same manner as eosio::chain::abi_serializer and user experience of cleos. Moreover, user can send a transaction with transaction_extensions by setting them in array like:

const tx = {
  actions: [{
  ...
  }],
  transaction_extensions: [[1, [1]], [2, [1, 2, 3, 4]]]
};

API Changes

• [x] API Changes

User will be able to pass action parameters by array instead of object.

Documentation Additions

• [x] Documentation Additions

User can pass an array to transact() of eosjs-api.

[tbfleming]

transaction_extensions must always be empty

[conr2d]

@tbfleming Interesting. Can you explain what the intended usage of transaction_extensions is?

I can understand there can be a planned way to use transaction_extensions in EOS mainnet in the future, but what about EOSIO-variants, called sister chains? They might utilize transaction_extensions fields not to modify libchain too much, but implement their own special features by parsing transaction_extensions in wasm-side.

Even if the emptiness of transaction_extensions is mandatory, this PR still has meaning, because this adopts the exisitng way to serialize struct like eosio::chain::abi_serializer does.

[tbfleming]

The intended use is to allow future hard forks to upgrade the transaction format. For now, the JSON representation requires either the field be absent or it be an empty array. The binary form requires a single 0 byte (this is how empty arrays are encoded).

If forks of eosio modify the transaction format, then we can't guarantee any compatibility with versions we maintain. Chances are high they'd conflict.

We were once considering supporting array syntax for objects in eosjs. I thought we had implemented that, but I could be remembering wrong.

[conr2d]

@tbfleming Thank you. :)