[wip] feat: embed TxEnvelope into rpc_types::Transaction

[klkvr]

Motivation

Closes #1165

Solution

• Added Envelope generic for rpc transaction which is consensus::TxEnvelope by default. For AnyNetwork we need a catch-all envelope, so I've extracted current rpc_types_eth::Transaction without block-related fields into AnyTxEnvelope type.
• Added Serialize and Deserialize for TxType. It deserializes as Option<U8> with None representing legacy and serializes as U8.
• Updated TxEnvelope to use custom deserialize impl to handle case of missing type field as legacy tx.

After this PR, Transaction will only implement arbitrary if k256 feature is enabled because of similar requirement on SignedAuthorization. I think this makes sense and believe we also want to add similar restriction for Arbitrary impl on Signed<T> which will only produce valid transactions.

At this point we are maintaining 6 very similar serde schemes + rlp encoding implementations for different tx holding types (5 tx types + AnyTxEnvelope). Wondering if we should add a macro for generating those so that serde attrs for e.g. gas are only defined once?

PR Checklist

• Added Tests
• Added Documentation
• Breaking changes

[gakonst]

breaking change?

[klkvr]

v on non-legacy transactions is deprecated, so that's a serialization change, deser should be fine

though we've decided to test this before merging

[yash-atreya]

Related https://github.com/alloy-rs/alloy/pull/865/files/d63e8e1498ab22b038e42ea0456ef9d68ed011ef#r1637954705

[klkvr]

The only breaking change this PR adds is for serde roundrip for rpc_types::Transaction. Earlier we wouldn't modify the serialized payload, but with this PR we will convert "v": "0x0 | 0x1" into yParity key with the same value.

This might only result in incorrect payload for legacy transactions as for them v is required. However, per EIP-155 spec:

then v continues to be set to {0,1} + 27 as previously.

Which likely means that it is safe to expect v on legacy transactions to always equal to 0x1c | 0x1b, thus never resulting in incorrect deserialization on our side

I've changed test fixtures because they contained v key with the same value yParity should contain. The change was required because during roundrip v was becoming yParity, thus failing assertions. Deserialization is still fine for previous fixtures, so there're no breaking changes for deserialization in this PR.

[klkvr]

Closing in favor of #1460