refactor(cli-extract-config): Generate configs without hive

[marioevz]

Description

Previous version of extract_config command required hive running to start up a client with each genesis.json from every test in order to extract the configuration files that hive generates for each client. It also required accessing docker containers prepared by hive where the clients were running in order to extract the configs from them.

This PR models all genesis configuration files for Geth, Besu and Nethermind as pydantic models in order to no longer have to use a running hive instance.

The models also now should be self-updating and require no to low maintenance.

E.g. Nethermind config file requires to list each EIP enabled in the fork, and this list already exists in the testing framework, so the list of activated EIPs will be updated automatically in the genesis config passed to nethermind, instead of having to manually update in ethereum/hive every time.

This also opens the door for us to automatically include these files in each release, however the file size could be prohibitively high and needs consideration.

Related Issues or PRs

N/A.

Checklist

• Ran fast static checks to avoid CI fails, see Code Standards & Verifying Changes: just static
• PR title has the form <type>(<area>): <title>, where <type> and <area> come from an appropriate C-<type>, respectively A-<area>, label. The title should match the target squash commit message.

Cute Animal Picture

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.54%. Comparing base (3d473e8) to head (ad5f74e).
⚠️ Report is 7 commits behind head on forks/amsterdam.

Additional details and impacted files

@@               Coverage Diff                @@
##           forks/amsterdam    #3414   +/-   ##
================================================
  Coverage            93.53%   93.54%           
================================================
  Files                  624      624           
  Lines                37074    37074           
  Branches              3394     3394           
================================================
+ Hits                 34679    34681    +2     
+ Misses                1645     1644    -1     
+ Partials               750      749    -1     

Flag	Coverage Δ
unittests	93.54% <ø> (+<0.01%)	⬆️

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

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[danceratopz]

It would definitely nice to avoid calling hive just to generate benchmark releases! I'm not entirely convinced this is the right approach, especially given the large code footprint. Who uses these artifacts atm? I believe, atm, it is only benchmarkoor? I'm curious how things would simplify if benchmarkoor took this over. But it looks like it might need to be on our side for sanity checking (can look deeper if need be).

But at the very least, I think we should move Nethermind over to use a geth-style genesis (valid from 1.38, released June '26):

• NethermindEth/nethermind#10046
• Hive-side PR ethereum/hive#1593
  Here's a quick cook from Claude with those changes on the benchmarkoor side, not less code on the face of it, but it could be simplified after the switch if it stops supporting old benchmark releases:
  ethpandaops/benchmarkoor@master...danceratopz:benchmarkoor:nethermind-geth-genesis

Otherwise, how about relying on hive's source, instead of running it. I.e., we could treat the mapper files as the source of truth? Requires a hive clone, but not to run it.

Btw, any reason you're prioritizing his now, btw? Just cleaning out the pipeline, ready for the next benchmark releases?

[danceratopz]

Just wanted to add. It's trivial to maintain this code these days, perhaps it's fine to add it 🙂

[danceratopz]

I revisited @raxhvl's approach in #2511 that uses hive's mapper files (as independently suggested above), and requires a clone, but not docker or a hive instance).

I prefer #2511's approach and think it's cleaner to let the consumer of these files generate the genesis; it's a better separation of concerns and gives a consumer more freedom to select:

1. test content version - which EEST release you consume,
2. transform version - which hive mapper vintage renders the configs,
3. client version - which client image/binary you actually boot.

This is what a consumer needs:

1. jq
2. hive's clients/<client>/mapper.jq files (checked out or vendored, pinned)
3. The ~15 lines of consume.sh: split the ingredients file, export the HIVE_* env, one jq -f mapper.jq per client.

I played around with it here, the required code footprint is minimal:

• https://github.com/danceratopz/execution-specs/tree/hive-genesis-demo/tmp

[raxhvl]

I think Dan is on top of this but Im here to help, if needed

[marioevz]

@danceratopz I think @raxhvl solution is the best one of the two, let's revisit and potentially rebase to prepare to merge some time in the future. I think the urgency of this is low, I thought this was somehow a blocker for Hegota devnet releases, but it's not, so feel free defer this until later. I'll close this PR for now!