txnprovider/txpool: refresh stale state views after OnNewBlock overtakes admission

[yperbasis]

Problem

AddLocalTxns and processRemoteTxns open their core-state transaction and cache view before acquiring p.lock. An admission request can therefore:

1. obtain a view of state version N;
2. wait for p.lock;
3. be overtaken by OnNewBlock, which applies state version N+1 and completes sender re-evaluation;
4. acquire the lock and mutate the pool using the old view.

This can bypass validation that depends on current sender state. For example, if the new block installs EIP-7702 delegation, the old view still reports empty code and several contiguous transactions can be admitted after the delegated-sender cleanup has already run. They enter pending, so the existing fallback that re-evaluates untouched queued senders on later blocks does not revisit them.

Pool reload has the same ordering risk: start opens coreTx before fromDB acquires the pool lock.

Reproduction

A deterministic test can use a blocking cache or DB wrapper:

1. initialize an EOA at nonce 0 with empty code;
2. start local admission, remote admission, or pool reload and pause after it opens the old state view;
3. update the account to nonce 1 with delegation code and let OnNewBlock finish;
4. release the paused operation with transactions at nonces 0, 1, and 2.

Expected: only nonce 1 remains.

Actual:

• local admission returns Success for all three transactions;
• remote admission retains all three transactions;
• reload restores all three transactions;
• the transactions are pending rather than queued.

The stale pending chain also survives a following block that does not change this sender.

Suggested direction

Establish a consistent ordering between the state view and p.lock. If OnNewBlock advances while admission or reload is waiting for the lock, reopen or retry the state transaction and cache view before mutating the pool.

Cover local admission, remote admission, and pool reload with deterministic regression tests.

Context

Found while reviewing #23294. That PR handles steady-state delegated senders and normal state-transition ordering; this race is a broader synchronization concern and should be handled separately.

#20998 describes a related re-evaluation refactor, but it does not prevent an operation from mutating the pool through an older state view after OnNewBlock completes.

[VBulikov]

yperbasis added Imp2 as Importance