We should allow `0x0` for `chainId` and `yParity` in EIP 7702 authorization lists

[acolytec3]

As reported by @yann300 , we currently check for no leading zeroes when validating authorization lists but we use validateNoLeadingZeroes which doesn't allow [0] since this function is primarily intended to check for leading zeros in RLP encoded bytestrings. The issue here is that RLP doesn't allow [0] since in RLP encoding, the value for 0 is represented as an empty array and so we don't allow arrays of greater than length 0 with the first element being 0.

We should adjust this section to use a different function for validateNoLeadingZero that allows for [0].

[holgerd77]

My suggestion would be that we add a second optional parameter to the method zeroAsEmpty = true which one can set to false and which then switches to a 00 -> 0 and 0 -> 0 behavior.

Makes sense?

[acolytec3]

Having re-read the EIP and our code again, I now think we should allow '0x0 for both yParity and chainId in the AuthorizationListItemJSON and then convert it to [] when we convert to AuthorizationListBytes

[jochem-brouwer]

Let's ensure this matches our behavior for decoding tx values like value: "0x0". It does not match this currently, but I think this (zero case) is the only case where do not match.

[jochem-brouwer]

The reason is hexToBytes("0x0") yields Uint8Array(1) [ 0 ] which causes the problem here. The correct bytes is Uint8Array(0) []. The value for txs gets decoded as bytesToBigInt(toBytes(x)). If x is "0x0" then toBytes yields the Uint8Array(1) [ 0 ], but if this gets encoded as bigint (BigInt(0)) the internally in tx we use the bigIntToUnpaddedBytes (instead of bigIntToBytes) which yields the correct bytes.