feat: Add EIP7702 tx handle logic for txpool

[Pana]

This PR is a mirror of Geth's relative PR ethereum/go-ethereum#31073

Which add two new rules for 7702 TX:

1. In addition to tracking transactions, the pool also tracks a set of pending SetCode
   authorizations (EIP7702). As a standard rule, any account with a deployed
   delegation or an in-flight authorization to deploy a delegation will only be allowed a
   single transaction slot instead of the standard number. This is due to the possibility
   of the account being sweeped by an unrelated account.

2. In case the pool is tracking a pending / queued transaction from a specific account, it
   will reject new transactions with delegations from that account with standard in-flight
   transactions.

[Pana]

Not sure the AllTransactions.auths clean logic is added correctly, please help check it

[mattsse]

I think this looks great already tysm, sorry for the delayed review.

the only real concern I have with this is that we're doing recovery inside the pool.

I see that we need to track auths, in the pool itself,
I can think of two ways to improve this, effectively the auths are additional metadata that we return as part of TransactionValidationOutcome::Valid, and we could track a list of auth sender ids in here:

reth/crates/transaction-pool/src/validate/mod.rs

Lines 260 to 264 in 3dd681b

	pub struct ValidPoolTransaction<T: PoolTransaction> {
	/// The transaction
	pub transaction: T,
	/// The identifier for this transaction.
	pub transaction_id: TransactionId,

then we don't need to deal with addresses and we can avoid moving the sender id map and don't need to do recovery in the pool, if the job of the validator is to recover those addresses and then we can map those to sender ids when we create and freeze the ValidPoolTransaction here:

reth/crates/transaction-pool/src/pool/mod.rs

Line 458 in 3dd681b

let tx = ValidPoolTransaction {

just like we do with the sender id

wdyt @Rjected

[Pana]

Thanks for your advice @mattsse

[Pana]

This PR solve issue #15079

[mattsse]

nice,

structurally this is now exactly how it should be done,

need some help from @Rjected reviewing the auth checks

[Rjected]

This makes sense, I only have some doc / style nits, could not find anything wrong with the checks. Some tests however for the new validations would be appreciated, although this could be done in a followup

[Pana]

This makes sense, I only have some doc / style nits, could not find anything wrong with the checks. Some tests however for the new validations would be appreciated, although this could be done in a followup

will add some tests in next pr

[Rjected]

I have just one comment on docs, otherwise this looks good to me

[Pana]

Hey @mattsse is there anything to do with this PR

[mattsse]

this looks complete now,, tysm

just need to test a few things before we can merge this

pending @Rjected

[Rjected]

This looks good to me!

[Rjected]

just needs clippy / compile fixes, trust that they are just from the api changes here

[Pana]

It's wired, the github action failure related code is different with my local code, seems there are some cache in somewhere. I will create a new PR for this change

[mattsse]

@Pana I think this is just some cargo.lock issue

[mattsse]

could you perhaps try after rebasing?

[Pana]

Thanks for your advice, some new added tests need to be sync and update