internal/ethapi: support "input" in transaction args

[fjl]

The tx data field is called "input" in returned objects and "data" in
argument objects. Make it so "input" can be used, but bail if both are
set.

Fixes #15628

[arrivets]

There is still a problem that raw transactions are decoded to core.types.Transaction which uses the 'input' field name for payload.

from Geth/internal/ethapi/api.go:

func (s *PublicTransactionPoolAPI) SendRawTransaction(ctx context.Context, encodedTx hexutil.Bytes) (string, error) {
	tx := new(types.Transaction)
	if err := rlp.DecodeBytes(encodedTx, tx); err != nil {
		return "", err
	}

The current javascript tooling to construct and sign transactions uses the 'data' field:

ex web3-eth-accounts:

Accounts.prototype.signTransaction = function signTransaction(tx, privateKey, callback) {
    var _this = this;

    function signed (tx) {

        if (!tx.gas && !tx.gasLimit) {
            throw new Error('"gas" is missing');
        }

        var transaction = {
            nonce: utils.numberToHex(tx.nonce),
            to: tx.to ? helpers.formatters.inputAddressFormatter(tx.to) : '0x',
            data: tx.data || '0x',
            value: tx.value ? utils.numberToHex(tx.value) : "0x",
            gas: utils.numberToHex(tx.gasLimit || tx.gas),
            gasPrice: utils.numberToHex(tx.gasPrice),
            chainId: utils.numberToHex(tx.chainId)
        };

Am I missing something?

[holiman]

@arrivets Yes, I think you are.. For the rlp-decoding, it doesn't matter what field is used internally. This PR would still accept current tooliing using data in the supplied json object.

[holiman]

I think this PR makes sense, but instead of failing if both are non-nil, it could check if they are equal first.

[arrivets]

ah yes of course.. thanks @holiman

[theblueskies]

The error message is a bit obfuscated. It's not entirely obvious from the error message that it will fail if the user supplies both. When two entities are mutually exclusive, it does not require that one be nil.

Perhaps it makes sense to have the error message something on the lines of: "Please supply either data or input."

[fjl]

PTAL

[holiman]

LGTM (have not yet tested, only looked at the code)

[fjl]

Rebased again to remove lint failure