fix mempool count overflow

[Oscar-Pepper]

Fixes: #2397

changed AtomicU8 to AtomicU32 to avoid overflow in the case of high volume of mempool txs

[dorianvp]

utACK

[dorianvp]

According to an LLM (I know uhhg), this is a fix to a symptom of a larger problem:

Since the sender blocks when the channel is full, the legitimate steady-state count is bounded at ~101 — comfortably inside u8. "High volume of mempool txs" alone cannot overflow a u8 here.

According to it, the part that does underflow is:

let _ignore_error = mempool_transaction_sender.send(raw_transaction).await;
unprocessed_transactions_count.fetch_add(1, atomic::Ordering::Release);

If the receiver side is gone, send fails instantly, the error is swallowed, and the counter increments forever with no matching decrements. That's the unbounded growth, and widening to u32 just moves the wrap from 256 increments to 4 billion. The correct fix is to only increment when send returns Ok

[Oscar-Pepper]

According to an LLM (I know uhhg), this is a fix to a symptom of a larger problem:

Since the sender blocks when the channel is full, the legitimate steady-state count is bounded at ~101 — comfortably inside u8. "High volume of mempool txs" alone cannot overflow a u8 here.

According to it, the part that does underflow is:

let _ignore_error = mempool_transaction_sender.send(raw_transaction).await;
unprocessed_transactions_count.fetch_add(1, atomic::Ordering::Release);

If the receiver side is gone, send fails instantly, the error is swallowed, and the counter increments forever with no matching decrements. That's the unbounded growth, and widening to u32 just moves the wrap from 256 increments to 4 billion. The correct fix is to only increment when send returns Ok

ok good point. so in practice this error can't be hit unless the whole sync fn has already been exited so it wouldnt matter, but i have added some extra precautions to avoid this wrapping in the case of the architecture changing in the future maybe allowing the mempool receiver to be dropped in some edge cases. i have kept the AtomicU32 for mempool count for similar reasons.. maybe in the future the mempool channel limit is raised beyond 256 risking overflow.