txpool: add support for set code transactions

[lightclient]

The new SetCode transaction type introduces some additional complexity when handling the transaction pool.

This complexity stems from two new account behaviors:

1. The balance and nonce of an account can change during regular transaction execution when they have a deployed delegation.
2. The nonce and code of an account can change without any EVM execution at all. This is the "set code" mechanism introduced by EIP-7702.

The first issue has already been considered extensively during the design of ERC-4337, and we're relatively confident in the solution of simply limiting the number of in-flight pending transactions an account can have to one. This puts a reasonable bound on transaction cancellation. Normally to cancel, you would need to spend 21,000 gas. Now it's possible to cancel for around the cost of warming the account and sending value (2,600+9,000=11,600). So 50% cheaper.

The second issue is more novel and needs further consideration.

There are a few issues we must carefully design around:

• Since authorizations are not bound to a specific transaction, we cannot drop
  transactions with conflicting authorizations. Otherwise, it might be possible to cherry-pick authorizations from txs and front run them with different txs at much lower fee amounts, effectively DoSing the authority. Fortunately, conflicting
  authorizations do not affect the underlying validity of the transaction so we can just accept both.
• TODO

A few situations to test:

1. Accounts with delegation set can only have one in-flight transaction.
2. Setcode tx should be rejected if any authority has a known pooled tx.
3. New txs from senders with pooled delegations should not be accepted.
4. Ensure setcode tx can replace itself provided the fee bump is enough.
5. Make sure that if a setcode tx is replaced, the auths associated with
   the tx are removed.
   5.1. This should also work when a self-sponsored setcode tx attempts
   to replace itself.
6. Verify nonces in setcode tx are at least valid when initially added to
   the pool, otherwise someone might submit old validations to deny
   service to unsuspecting users.

maybe try to write out each possible scenario for all types of txs entering the
pool +different 7702 situations and consider outcomes?

[rjl493456442]

Any particular reason for tracking the tx object itself, rather than the tx hash?

[rjl493456442]

We have to add the SetCodeType support in the txpool, https://github.com/ethereum/go-ethereum/blob/master/core/txpool/legacypool/legacypool.go#L280