Composite Scenarios Execution - Setup parallely, spam parallely (and in stages)

[arpitkarnatak]

Motivation

This PR is step 1 for composite scenario execution, as suggested in #145

Solution

Adding a new compose command, similar to docker compose

Composite scenario execution, setup and spam multiple contracts from a single YML file.

Usage: contender compose [OPTIONS]

Options:
  -f, --filename <FILENAME>
          File path for composite scenario file
          
          [default: ./contender-compose.yml]

A contender-compose.yml file looks like

setup:
  simpler:
    testfile: ./scenarios/simpler.toml
    min_balance: 12.1

  uniV2:
    testfile: ./scenarios/uniV2.toml
    rpc_url: http://localhost:8545 # Optional
    min_balance: "11"
    env:
      - Key1=Valu1
      - Key2=Valu2
    private_keys: # Optional (these Private keys are from Anvil)
      - 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80
      - 0x59c6995e998f97a5a0044966f0945389dc9e86dae88c7a8412f4603b6b78690d
    tx_type: eip1559  # Optional

  uniV3:
    testfile: ./scenarios/simple.toml
    rpc_url:  http://localhost:8545 # Optional
    min_balance: 0.01  # Optional
    tx_type: eip1559  # Optional

Currently this only supports setup command, it parses a contender-compose.yml file and deploys multiple contracts from a single contender compose command.

The next step would be to include the spam from this file. Before implementing that, I want to know if all these spams are going to be run parallely and fall under a single run ID, or be separate runs one after the other.

Also, I feel it would be better to have all the logic for the compose file to be a separate crate of its own, similar to testfile. Let me know your thoughts, and any feedback on how to improve/move forward with this.

PR Checklist

• Added Tests
• Added Documentation
• Breaking changes

[zeroXbrock]

@arpitkarnatak this is sick, thanks for the PR!

The next step would be to include the spam from this file. Before implementing that, I want to know if all these spams are going to be run parallely and fall under a single run ID, or be separate runs one after the other.

They should all run in parallel with different run IDs. Something I'd like to add in the "compose config" is the ability to define dependencies, so that we may execute them in sequence, but I think the default should be to run them all together at once.

Also, I feel it would be better to have all the logic for the compose file to be a separate crate of its own, similar to testfile. Let me know your thoughts, and any feedback on how to improve/move forward with this.

Yeah I agree, this should live in its own crate.

[arpitkarnatak]

@zeroXbrock Thanks for the feedback.

So I'll have to do the following next

1. Implement spam and it's relevant parameters for running multiple scenarios parallely.
2. Add a depends_on for setup command so if we have to run certain scenarios sequentially.
3. Move the logic for compose file into a new crate of its own contender_composefile.
4. More detailed documentation on contender-compose.yml file specs.

I have one little doubt,

Currently I'm using the pre-existing setup() and spam() functions from inside the compose file. Are we supposed to use that only or take the logic pieces from it into the new compose() function. Pros for using existing functions: Less lines of code, no code repetition , even docker does the same. Cons would be, jumbled logs for all the different scenarios, since each scenario/set of scenarios will be a separate task)

[arpitkarnatak]

@zeroXbrock So I've done the following

1. Added spam into compose file, with the stages as mentioned in the requirement. The setups run parallely, and so do the spams for each stage.
2. contender_composefile is a separate crate now.
3. There's some documentation for compose file now, highlighting how it maps to the spam and setup commands

Some things that I've had confusions with.

1. I wanna hold off on implementing depends_on for now, since those dependencies exists in the scenario.toml file itself (as per issue scenario file dependencies #253) so I guess we might wanna be done with scenario file dependencies #253 before this.
2. There are a few parameters seed, engine_params in SpamCommandArgs and SetupCommandArgs which I don't understand what they mean or wasn't able to make sense of (as in where they come from), so those are hardcoded.

I want to do the following before merge

1. Write some more tests for the new crate composefile.
2. Adding additional documentation on each and every parameter of the contender-compose.yml file.

But apart from that, it's ready for review, do let me know what needs fixing/clarity

[zeroXbrock]

@arpitkarnatak thanks for the PR! I should have time later in the week to review