Add option to run indefinitely

[scharissis]

Description

Right now when running spam executions (or stages in campaign mode), you have to specify a duration or transaction count. It'd be really useful to have an option to just let it run forever until manually stopped.

Not sure if this should apply to:

• Just spam mode
• Campaign stages individually
• Entire campaigns

But having it at least for basic spam mode would be super helpful!

Use case

• Long-running load tests where you want to manually monitor and stop when you see certain conditions
• Continuous background load generation
• Testing stability over extended periods without having to guess at durations upfront

Proposed solution

Maybe something like --indefinite flag or allowing --duration=0 to mean "run until interrupted"?

[zeroXbrock]

@scharissis I believe this already exists: contender spam has a --loops [num_loops] flag which lets you specify the number of times the spam run will repeat, or if no argument is provided, it will loop indefinitely. So typically instead of setting a high duration, we'll set duration low (usually 10-20) and then loop as needed.

That said, I should probably add some docs to make this feature easier to find. I also wonder if the --loops flag really provides an acceptable UX. A specific --indefinite flag would be easier to spot at a glance in the help menu, and --loops isn't easy to spot when looking for something like "run indefinitely".

tangentially related, feel free to ignore:
I also think --loops might just go away altogether. For context, I'll explain why --loops exists in the first place:
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.

But instead of using --loops with low durations, I think the thread that sends the tx should also await its receipt and send the info to the DB. Then duration can just be long, loops can be deleted, and then we'd add a new --indefinite or --infinite flag that works with the new design. That way 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.

However, this is a big enough change to have its own PR -- I'll write it up in a new issue.

[zeroXbrock]

However, this is a big enough change to have its own PR -- I'll write it up in a new issue.

• wrote up the issue here: refactor spammer: async pendingTx cache processing #395
• PR to implement it here: feat/async cache processing #396

that ^ PR will also include a replacement for --loops

[zeroXbrock]

@scharissis wdyt of this new PR? It replaces --loops with --forever and processes receipts async, so we don't pause spamming to wait for receipts. It doesn't currently work for campaigns -- do you think it would be useful if it did?