fix: pending transaction ordering

[klkvr]

Closes #12340
Closes #12286

Updates the way transaction adding is handled in Pending pool.

• add_transaction now correctly handles inserted transactions and does not make assumptions on their order. This is done by stroing a mapping sender -> higher/lower nonce instead of a simple set of highest/lowest transactions
• whenever we update BestTransactions we now pre-sort the transactions vec by nonce to make sure that there will be no nonce gaps. I didn't apply same approach as with pending pool here because we insert pretty rary and need ability to get the independet tx with highes priority which is hard to do in a nice way with a hashmap

[mattsse]

style nits

[mattsse]

this looks a bit weird, why can we no longer process txs one by one?

how many txs are buffered in new_txs is arbitrary, so doesn't make sense that we have to sort this arbitrary chunk

[klkvr]

updated BestTransactions, it now holds the following:

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

Lines 77 to 83 in 311a10d

	/// Transactions that can be executed right away: these have the expected nonce.
	///
	/// Once an `independent` transaction with the nonce `N` is returned, it unlocks `N+1`, which
	/// then can be moved from the `all` set to the `independent` set.
	pub(crate) independent: BTreeSet<PendingTransaction<T>>,
	/// Mapping from sender to lowest nonce of its transactions in the pool
	pub(crate) lowest_nonces: BTreeMap<SenderId, u64>,

when inserting, we make sure to replace independent tx if the nonce of tx being added is lower than the lowest we know for the given sender

that way we still don't make assumptions on order of transactions and don't have to sort everything

[mattsse]

lgtm