feat(fixtures/specs): Transaction tests

[marioevz]

🗒️ Description

Transaction Test Format

Introduce the Transaction test type to EEST.

TODOs:

• Correctly calculate the intrinsic gas of the transactions when valid
• Documentation
• Migrate some tests from ethereum/tests

At the moment the spec only generates the transaction fixture type, and automatically generating blockchain and engine blockchain tests could be added in the future.

Fixture format type in _info

A new info key fixture_format is added to the _info dictionary in the generated fixtures.

This is done in order to better discriminate between fixture formats, since the addition of the transaction test format was causing issues in checkfixtures command.

🔗 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: All converted JSON/YML tests from ethereum/tests have been added to converted-ethereum-tests.txt.
• Tests: A PR with removal of converted JSON/YML tests from ethereum/tests have been opened.
• 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.

[winsvega]

Look at transaction test filler
It has no pre state.

We used to have t9n in geth to ask the client for transaction test validity

Now we have python implementation of transaction
So we can generate tests no problem.

Basically its like difficulty test. Lets say we test data field.
So we put all other tx fields to be of valid value.

Then we iterate by forks by tx types.
And we iterate data by vector of tests.

Data is empty - tx valid
Data is 00 - valid
Data is 32 random bytes - valid
Data is max_tx_data sise - valid
Max size+1 - invalid
Data size is uint64 +/- 1
Data size is uint128 +/-1
Data size is uint256 +/-1

The exception here is.
Intrinsic tx validation. So tx with gaslimit 0 is a valid structure. But it will be rejected as invalid because we validate intrinsic tx gaslimit rule

In this tests we don't care about pre or post state and out of funds exceptions or out of gas exceptions

Same for gaslimit field.
So I don't see how you want to run it on a bc because you will have to set block gaslimit and account with enough funds.

While transaction structure remains valid.

Also for int fields we test rlp encryption.
Field is 80 field is 6000 field is prefixed by 00(invalid)

This test you can also treat as transaction deserialization tests from rlp. Because we can put an extra field in rlp or remove one. Or mess rlp headers.