feat: Introduce SSZ model into base types

[RazorClient]

Description

This PR introduces the sszmodel as a descendant of the camelmodel. Its major work is to introduce a Pydantic model which has ssz inbuilt and can transform its members into remarkable-ready ssz-friendly types.
An extension of pr is to add the randomisation machinery for the ssz types as a port from the SSZ Static from here

The code for randomisation and the ssz static vector generation can later be moved to a different pr,however putting it here just for initial visibility.

Related Issues or PRs

#2645

Checklist

• Ran fast static checks to avoid CI fails
• PR title has the form <type>(<area>): <title>, where <type> and <area> come from an appropriate

Cute Animal Picture

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.39%. Comparing base (ccab088) to head (f197028).
⚠️ Report is 25 commits behind head on forks/amsterdam.

Additional details and impacted files

@@                 Coverage Diff                 @@
##           forks/amsterdam    #3196      +/-   ##
===================================================
+ Coverage            93.31%   93.39%   +0.08%     
===================================================
  Files                  624      624              
  Lines                36994    37014      +20     
  Branches              3384     3386       +2     
===================================================
+ Hits                 34521    34570      +49     
+ Misses                1693     1671      -22     
+ Partials               780      773       -7     

Flag	Coverage Δ
unittests	93.39% <ø> (+0.08%)	⬆️

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.

[marioevz]

Overall LGTM.

I just added two minor comments in the entire PR.

I think sane next steps would be to start modifying existing models to add SSZ functionality where required, but without enabling it at first, just so we can verify using hasher that the fixtures before and after are exactly the same.

After that we can start modifying the test fixtures in order to add SSZ variants to the engine API execution payloads where possible.

Then we can start modifying the test consumers to use them.

[marioevz]

I'm assuming something like this will replace the existing models that are generated for the test fixtures, e.g.

execution-specs/packages/testing/src/execution_testing/fixtures/blockchain.py

Line 389 in 9e9bf90

class FixtureExecutionPayload(CamelModel):

One question is whether we can keep the format of having a single model that declares future-fork fields as None | Type, and then None is set by previous forks where this field does not appear so it's omitted from the JSON output. How would this work with SszModel? Ideally we should keep one model to which we keep appending optional fields for future forks.

[RazorClient]

This would not be possible with the current design as it stands rn as it is structurally not supported by SSZ to have no fields per se(bcoz of ssz being positional.)
However, that being said, I'm looking into it a bit more to find a solution to this
The single-model format itself looks preservable.I'm working out the cleanest shape for that and will follow up tommorow

[RazorClient]

Hey directionally, that would make sense.
Having diffs with hasher is the best way to make sure no regression occurs.
However just adding ssz variants to the engine api testing(yes, some of it might work but to faithfully test out the 793 changes) would not work per se and this would require a few more changes here and there,but that we can discuss on the meet and align towards the direction