Overlay-only mode fixes to prevent occasional banned transaction drops

[marta-lokhova]

A fairly obscure edge case in overlay-only loadgen mode: because we don't update seqnums in the DB, it is possible to generate transactions that are duplicates of already applied transactions. Because we ban applied transactions, and pull mode rejects banned transactions, the network ends up not pulling some new transactions at all. This causes a few transactions per run to get dropped, and trips loadgen.

The fix is to avoid ever loading seq nums from DB during overlay-only mode, and always bump sequence number for every new transaction.

[Copilot]

Pull request overview

This PR aims to fix an overlay-only loadgen edge case where sequence numbers can regress to stale DB values, causing regenerated transactions to duplicate already-applied transactions (which then get banned and can be dropped in pull-mode propagation).

Changes:

• Introduces TxGenerator::maybeLoadAccountSequenceNumber() and uses it to avoid DB sequence-number reloads in overlay-only mode when generating Soroban-related transactions.
• Tightens overlay-only assumptions in loadgen by asserting txBAD_SEQ recovery paths aren’t exercised in overlay-only mode.
• Makes banned-transaction handling consistent in TransactionQueue::canAdd() (removing the overlay-only test-build bypass).

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
src/simulation/TxGenerator.h	Adds a helper declaration to conditionally reload account seqnums.
src/simulation/TxGenerator.cpp	Uses the helper to skip DB seqnum reloads in overlay-only mode across several Soroban tx builders.
src/simulation/LoadGenerator.cpp	Adds overlay-only assertion on txBAD_SEQ handling and changes how pregenerated txs affect local seq tracking.
src/herder/TransactionQueue.cpp	Simplifies banned-tx handling to always return TRY_AGAIN_LATER (also in test overlay-only).