Race condition in SenderInfo::update may cause nonce regression

[will-2012]

Description

There is a potential race condition in SenderInfo::update that can cause
the tracked state_nonce to regress (go backwards), which may incorrectly
affect transaction pool state.

Problem

In crates/transaction-pool/src/pool/txpool.rs:

impl SenderInfo {
const fn update(&mut self, state_nonce: u64, balance: U256) {
*self = Self { state_nonce, balance }; // Directly replaces!
}
}When add_transaction is called, it updates sender_info with the state_nonce
from validation:

self.sender_info
.entry(tx.sender_id())
.or_default()
.update(on_chain_nonce, on_chain_balance);### Race Condition Scenario

1. Block N is committed, on_canonical_state_change updates sender_info.nonce = 5
2. A P2P transaction arrives, validation calls client.latest() which may return
   slightly stale state (nonce = 4)
3. Transaction is added, sender_info.update(4, balance) regresses nonce from 5 to 4

Impact

• Transactions with nonce 5 in the pool may be incorrectly marked as having a nonce gap
• Transactions may be demoted from pending to queued incorrectly

[will-2012]

Please help confirm whether such a problem is possible.

[mattsse]

hmm, I believe this is technically reachable yes

maybe we should pick the max value here?

[will-2012]

self.all_transactions.insert_tx may also bugily cause a nonce too low if it enters the pending queue, or result in an incorrect gapped transaction if it enters the queued queue~