refactor spammer: async pendingTx cache processing

[zeroXbrock]

Is your feature request related to a problem? Please describe.

For long-running spam runs, contender uses --loops, which repeats a spam run (a spam run is sending --tps N transactions for --duration T). --loops is not a good design -- it should be replaced.

Context:

When contender starts spamming, it (only) sends spam txs, caching the tx hashes in memory until the full duration has elapsed. Then once all the txs are finished sending, we get receipts for all the cached tx hashes and save whatever data we need from them to the DB for use in reports. This spam/get_receipts process happens once in each loop. By setting a low duration and looping, we keep the size of the tx_hashes cache manageable, so we don't have to wait for 5000 receipts and potentially overwhelm the RPC.

Problem:

When a batch/loop finishes, contender stops spamming to fetch receipts & save data to DB. Spamming should continue seamlessly, while pending tx processing happens in the background.

Describe the solution you'd like

Currently, each spam task sends its tx hash to a TxActor once the tx is successfully sent, which caches the tx hashes in the background (see Spammer::spam_rpc for reference). Then once we finish sending spam txs, we call flush_cache to get receipts & save data to DB.

The existing separation between spamming (wrt the Spammer trait) and result-processing (wrt TxActor) is something we should keep, we just need to change how we call flush_cache.
I think the best solution is to make TxActor regularly call flush_cache in the background, rather than calling it from Spammer::spam_rpc.

Then finally, we'll remove --loops and incorporate a new --indefinite (or --infinite?) flag to enable endless spamming.

Benefits:

• we don't stop spamming to collect receipts
• we don't have to confuse users with real_duration = duration * loops logic, and the RPC traffic will be all-around more realistic.

Describe alternatives you've considered

• integrate receipt-fetching logic into spam-tx task
  • downsides: may require major DB changes & hurt performance (esp. bc of the DB)
  • upside: easy to reason about

Additional context
Add any other context or screenshots about the feature request here.