composite scenario execution

[zeroXbrock]

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

I've gotten a lot of requests for the following functionality:

• run multiple scenarios in parallel (e.g. UniV2 and UniV3)
• run scenarios in stages (e.g. start low-pressure, then ramp up the intensity over time)
• run a scenario indefinitely

Describe the solution you'd like

I think all these features can be supported with the implementation of a new "meta-scenario" definition. Similar to docker-compose, we could offer a new command that runs scenarios from a new config-file spec that specifies an array of steps, whose parameters are functionally equivalent to the CLI's spam command.

Example meta-config spec:

setup:
- stress.toml
- uniV3.toml:
  - min_balance: 21

spam:
  loop:
  - scenario: stress.toml
    tps: 5

  stages:
    warmup:
      scenario: stress.toml
      tps: 10
      duration: 10 # seconds because we used `tps`
    regular:
      - scenario: stress.toml
        tpb: 20
        duration: 10 # blocks because we used tpb
      - scenario: uniV3.toml
        tpb: 10
        duration: 10
    max_heat:
      - scenario: stress.toml
        tpb: 40
        duration: 30
      - scenario: stress.toml
        tps: 25
        duration: 30
      - scenario: uniV3.toml
        tps: 25
        duration: 30

This example is just a first pass but this format provides a nice base for expansion. Longer-term, I'm thinking we could add more advanced parameters, to do things like gradual ramping of tx volume, specify different seeds for fuzzing/account generation, or even specify alternative fuzz-seeder implementations to produce deterministic sequences required for more complex scenarios that rely on chain state and/or prior state alterations.

Describe alternatives you've considered

• I considered accepting multiple scenario files as positional arguments to the spam command, but that wouldn't scale well, as one scenario might consume significantly more gas/eth than another, leading to one scenario inadvertently getting blocked by another.
• A stop-gap solution I've been using is writing shell scripts to run muliple instances of contender (with different seeds to avoid nonce conflicts)

[arpitkarnatak]

Can we break this down into 2 different tasks?

1. Running setup and spam from a yaml file for a single scenario. (by introducing something like a file called scenario.yaml and we just do contender setup and contender spam and it would read params from this file.)
2. Configuring setup and spam for multiple scenarios (since we might wanna randomize the transactions, have it all under a common run id, have a common report of all the different spams). Since the reading params from yaml file would exist already, it would be simpler to expand the functionality rather than doing a one large PR.