feat(fw): Implement ModelGenerator, implement Transactions and Withdrawals

[marioevz]

🗒️ Description

Adds a ModelGenerator class which can be used to implement generators of pydantic models, such as Transaction and Withdrawal.

ModelGenerator is used as:

class Transactions(ModelGenerator, model=Transaction, index_field="nonce"):
    pass

and generates a new class that takes the same arguments for instantiation, but also takes an Iterable in each field.

When an Iterable is provided, a generator is instantiated that produces one instance of the model per element.

ModelGenerator automatically detects which fields of the model are already supposed to be lists (iterables), and accepts a new field with an _iter suffix and treats each as an iterator to generate the lists.

E.g. In the Transaction class, the field access_list is already supposed to be a list, so the ModelGenerator accepts a new field called access_list_iter where the user can specify the iterable for this field that generates the access_list field for each generated transaction.

This PR implements Transactions and Withdrawals, and modifies usages in many tests as examples.

🔗 Related Issues

None

✅ Checklist

• All: Set appropriate labels for the changes.
• All: Considered squashing commits to improve commit history.
• All: Added an entry to CHANGELOG.md.
• All: Considered updating the online docs in the ./docs/ directory.
• Tests: Included the type and version of evm t8n tool used to locally execute test cases: e.g., ref with commit hash or geth 1.13.1-stable-3f40e65.
• Tests: Ran mkdocs serve locally and verified the auto-generated docs for new tests in the Test Case Reference are correctly formatted.

[spencer-tb]

Super nice!

[spencer-tb]

Really nice, I checked to see if we could use these in other tests but couldn't find anything!

I wondered if we could do something similar for pre/post accounts, or even blocks but I don't think the value is weighted.

We should add tests for withdrawals tests/test_withdrawals.py and add a section to the documentation for this.

When I update: #61 - I will use Transactions - so I can mention these in the documentation too

[marioevz]

When I update: #61 - I will use Transactions - so I can mention these in the documentation too

Yes please 👍 we definitely need some examples in the docs for this.

I think the Blocks case should be doable. I haven't thought too much about it but I don't see why this could not be done.

[marioevz]

This PR is affected by the pydantic changes, so potentially needs to be reworked.

Converting into draft until rework is done.

[marioevz]

Rebased on top of #486, which was surprisingly easy, but now it requires that PR to be merged first.