Use input as data in eth_sendTransaction

[jiexi]

The Ethereum execution API specs have eth_sendTransaction with a input field, however nodes such as geth have been using the data field instead, adding input support later.

To make eth_sendTransaction align better with execution api, this PR makes eth_sendTransaction accepts input OR data (if both are provided, they must be equal) and maps it to the data field in the object that the processTransaction callback expects

See: https://github.com/MetaMask/MetaMask-planning/issues/2214

[legobeat]

For initial maximal compatibility, how about setting both input and data, removing one in a follow-up release?
After this change, input is now a special case filtered out from output while any other free-name fields are still passed through. This is a bit counter-intuitive and might be good to do in a two-step process?

Suggested change

	...(txParamsData ? { data: txParamsData } : undefined),
	...(
	txParamsData
	? { data: txParamsData, input: txParamsData }
	: undefined
	),

[jiexi]

done here b47e1ba

[shanejonas]

are we sure we want to set both? the original geth PR says:

bail if both are set

[legobeat]

Should we really modify the params at all? Considering there are other implementations which may work differently. Maybe the validation that both aren't provided with differing values is enough for the sake of this package?

[jiexi]

The only consumer of this should be TransactionController, which drops input (and other unexpected fields) as one of the first steps of transaction processing

[legobeat]

This is a public package with external dependents who rely on the current API, though, which also need to be considered.
https://www.npmjs.com/browse/depended/@metamask/eth-json-rpc-middleware

There are likely other dependents as well, which don't necessarily show up on npmjs.

[legobeat]

MetaMask is also actively advising existing users of deprecated web3-provider-engine to migrate to @metamask/eth-json-rpc-middleware.