tx: implement tx containers and tx workers [WIP] [Experimental]

[jochem-brouwer]

Part of #3733

This PR:

• Introduces the new "tx container" which (once PR is ready) should replace the current Tx classes we use
• The tx container class holds the tx data
• What is done with the data (e.g. extract data fee, find sender address) is leveraged to the tx worker which looks at the data itself to figure out what to do (specifically: what "features" does it support?

SUPER WIP. Only here to show the current line of thought.

Things I plan to do:

• Move methods which extract/convert input to the desired output (so basically reading types like BigIntLike and converting those to bigint in the constructor) to a central place and make the tx container constructors consume these
• Write more tx worker methods
• Figure out if we want the sign method on the tx or seperately
• Make the types a bit less chaotic

[paulmillr]

As a side note, in eth-signer, the goal with Transaction class was to make it friendly and easy to debug. Viewing something like this in logs is great:

Transaction {
  type: 'eip1559',
  raw: {
    to: '0xdf90dea0e0bf5ca6d2a7f0cb86874ba6714f463e',
    value: 1100000000000000000n,
    nonce: 0n,
    maxFeePerGas: 100000000000n,
    maxPriorityFeePerGas: 1000000000n,
    gasLimit: 21000n,
    accessList: [],
    chainId: 1n,
    data: '',
    type: 'eip1559'
  },
  isSigned: false
}

Some libraries use hex in logs, which is not cool.

[jochem-brouwer]

Hi Paul, thanks, the old and this proposed "new" interface both will have the property fields either bigint, Uint8Array, Address or a nested list of Uint8Array, so I guess that's change. The toJSON() method will output these fields in a stringified format 😄

[jochem-brouwer]

Marked as blocked since this is highly experimental.

[jochem-brouwer]

Closed in favour of #3796