Add Support for BlockchainTests

[marioevz]

Changes Included

• Adds support for multi-block tests, which are necessary to verify behavior that transcends a single block, such as basefee calculation, fork transitions, withdrawals, blobspace transaction fees calculation, etc.
• Adds requirement for rlp module import, because t8n tool currently returns transactions' RLP that includes rejected ones, and these should be removed before producing the final block.
• Introduces new types to better make a distinction between the types that are used to describe a test and the ones used to format the inputs to the transition or the block tool.

ToDos

• Requires cmd/evm: calc base fee if parent data is present go-ethereum#26051 to properly work, since this PR introduces currentBasefee as output of the execution result.
• mypy is currently complaining about the usage of kw_only property of dataclass.
• Use kw_only on all dataclass classes to force test specs to specify keywords when declaring test objects. The argument to this is that it allows the objects to be updated in the future and not having to refactor all tests due to positional argument conflicts.

[lightclient]

Some small comments and nits, overall looks great!

[lightclient]

If only one is set, will the other be set automatically? I think yes?

[marioevz]

I think it will fail, I checked geth code and it requires both, since there is no way to deduce the other value if only one is set I think.

[marioevz]

The only remaining issue seems to be whether to include or remove the invalid transactions from blocks.

I can follow up on this in a subsequent PR if that's ok.

[lightclient]

I might be missing something, but it feels like this PR is making an active choice to remove invalid transactions from the RLP and so we should remove that logic from this PR and decide the best way to deal with invalid txs separately. Is there a reason that work is necessary for this specific PR?

[marioevz]

I might be missing something, but it feels like this PR is making an active choice to remove invalid transactions from the RLP and so we should remove that logic from this PR and decide the best way to deal with invalid txs separately. Is there a reason that work is necessary for this specific PR?

No it was just simply to keep from adding more and more modifications to the PR, but yes now that you mention it, we should not be adding a new import that we are supposed to remove in another PR. Let me add the changes in this PR 👍

[lightclient]

Looks good to merge once CI goes green!