op-e2e: Support specifying allocs in tests

[mslipper]

Overview

Previously, the E2E test suite read a hardcoded set of allocs from the .devnet directory. There could only be one logical set of allocs per test suite run. To get around this limitation, we added matrix jobs to the CI pipeline that swapped in different versions of the allocs for alt-DA, MT Cannon, fault proofs, and the L2OO. This was very inefficient and complex: most tests don't need to run against multiple versions of the allocs, and were running 4 separate build jobs when only one was needed.

This PR makes it possible for an individual test to request a specific allocs file. We can now run tests for multiple different configurations of the OP Stack - e.g. alt-DA, L2OO and fault proofs - in a single test run.

To make this work, I updated the test suite's initialization method to read alloc files from multiple suffixed .devnet- directories. I made a a new make devnet-allocs-tests task to generate them. The allocs are then added to a map, and the rest of the tests use getter methods in the config package to locate the appropriate configuration structs.

Reviewing this PR

This PR seems large, but most of the modified files contain limited changes to comply with the new API for selecting test configuration based on alloc type. For example, an allocType configuration parameter was added to various system config structs and the DefaultRollupTestParams variable was made into a method so that it always returns a copy for easy extension. The important logic happens in the following files:

• Makefile
• .circleci/config.yml
• op-e2e/config/init.go

As part of this PR, I also cleaned up a few issues:

• I removed the external OP Geth shim. It wasn't used anywhere, and was introducing a lot of complexity for little gain.
• I refactored some tests to use top-level test methods rather than subtests so that they could be more easily parallelized.
• I removed references to UseFaultProofs, UseAltDA, and other environment-based test flags from test utilities. We shouldn't be reading from the environment in test utils. Instead, we should pass in the behavior we want to the test utils themselves.

[semgrep-app]

Semgrep found 1 sol-style-input-arg-fmt finding:

• packages/contracts-bedrock/src/libraries/Encoding.sol
  • L229-230 - Triage

Inputs to functions must be prepended with an underscore (_)

_{Ignore this finding from sol-style-input-arg-fmt.}

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 74.97%. Comparing base (31e244c) to head (d9d2de9).
Report is 3 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop   #12216      +/-   ##
===========================================
- Coverage    75.19%   74.97%   -0.22%     
===========================================
  Files           49       49              
  Lines         3665     3665              
===========================================
- Hits          2756     2748       -8     
- Misses         736      745       +9     
+ Partials       173      172       -1     

Flag	Coverage Δ
cannon-go-tests	74.97% <ø> (-0.22%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

see 1 file with indirect coverage changes

[ajsutton]

LGTM. Seems like a big improvement in flexibility that we can keep building on to support completely custom configs at some point without having to pre-generate them.

I'm not entirely sure what the mt-cannon tests are doing - they seem to still have some special treatment. Given we now have multicannon which will select the right version of cannon to run automatically based on the prestate, we should be able to just have tests that actually run cannon setup to run their tests with both Standard and MtCannon allocs and have it just work.

I also put up #12221 which reads the AllocType from the System when configuring the challenger so it doesn't need to be pulled from the env which maybe helps with part of that too.

[ajsutton]

Confirmed that the MT cannon tests can just run as a standard alloc type with #12221. No need for special env vars. 🎉
We can then setup the cannon tests to run both variants pretty easily. They are our most expensive tests though so may want to think carefully about which tests we actually want to test both variants on - often they're testing the dispute game and challenger's ability to run cannon more than cannon itself.