revert MEV SSZ changes

[tersec]

This is requiring a Eth-Consensus-Version. This is required since

• Add SSZ support to builder api ethereum/builder-specs#104

in https://github.com/ethereum/builder-specs/releases/tag/v0.5.0

But it's evidently not yet widely enough implemented to be relied upon, quite yet, so revert for now. It should be feasible when dropping the Deneb builder API to unconditionally assume this again.

[tersec]

ignoring copyright year linter, want as clean a "revert" as possible

[arnetheduck]

why not simply assume deneb if the header is missing? we can also tell from the ssz data which fork it is, the header is just extra noise

[tersec]

why not simply assume deneb if the header is missing? we can also tell from the ssz data which fork it is, the header is just extra noise

1. no more autodetection, it's ugly and fragile and hard to maintain. I ripped it out of the JSON parts as much as I could before and all those likely-broken heuristics based on presence/absence of random JSON fields are gone too, not adding it back unless it's absolutely 100% required. it isn't here;

2. also the caller knows, there's only one right answer indeed. Nimbus had this getHeaderDeneb/getHeaderElectra/getHeaderFulu which, same REST API call but with the function call graph/type system encoding that right answer, in a statically type-safe way with no runtime overhead. either it decodes as the correct fork or it doesn't. from this perspective that header is just noise. assert it's correct if one wants, but it's not required or useful; and

3. "assume deneb" is a shifting target as different testnets/mainnets (Gnosis, EF, etc) fork at different times, it's also fragile to hardcode that before.

• Add SSZ encoding support to MEV client calls. #6970

is the PR which did this, and it got rid of these https://github.com/status-im/nimbus-eth2/blob/v25.3.0/beacon_chain/spec/mev/rest_deneb_mev_calls.nim / https://github.com/status-im/nimbus-eth2/blob/v25.3.0/beacon_chain/spec/mev/rest_electra_mev_calls.nim / https://github.com/status-im/nimbus-eth2/blob/v25.3.0/beacon_chain/spec/mev/rest_fulu_mev_calls.nim with their getHeaderFoo/getHeaderFooPlain/submitBlindedBlock [which because it's overloaded on the static body type, it knows the kind of response it will get]. So it before this PR it always, 100% of the time, assumed whatever the fork scheduled said to use. That was fine.

In this case, part of the machinery for adding SSZ support removed this infrastructure. They could coexist, but that PR didn't approach it that way.

[tersec]

The main reason not to merge this, really, is that we'll probably find out in 2 days that we'll need to do a mainnet release this month regardless.

[arnetheduck]

I ripped it out of the JSON parts

Well, there seems to be a sequencing problem here at the very least - ie the rest server must support the beacon api as it was specified at the beginning of deneb - v0.5.0 is newer than that, so until electra happens, the old implementation should have stayed as-is with whatever electra news being added on top of that.

[github-actions]

Unit Test Results

       15 files  ±  0    2 625 suites   - 5   1h 14m 7s ⏱️ -27s
  6 330 tests  -   9    5 828 ✔️  -   9  502 💤 ±0  0 ❌ ±0 
44 071 runs   - 45  43 393 ✔️  - 45  678 💤 ±0  0 ❌ ±0 

Results for commit 807c0c0. ± Comparison against base commit 62a99df.

[tersec]

#7045 is a better approach