feat(tests): add worst-case block test for 7702 set code

[LouisTsai-Csie]

🗒️ Description

Add blockchain test for EIP-7702 set code transaction.

🔗 Related Issues

Issue #1453

✅ 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/tests/static have been assigned @ported_from marker.
• Tests: A PR with removal of converted JSON/YML blockchain 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.
• Tests: For PRs implementing a missed test case, update the post-mortem document to add an entry the list.

[marioevz]

We probably need to pre-set these to an authorization for the reset to do something.

Suggested change

	sender = pre.fund_eoa()
	sender = pre.fund_eoa(delegation=Address(0x1))

[jsign]

Agree, but sounds it would only have effects for the first tx of the list. Starting with the second and further txs, the delegation will be considered a noop, no? So most tx won't be doing any real work.

I wonder if this test should probably:

• Try calculating the maximum number of delegations possible for gas_limit (and remove the iteration_count parameter).
• Create N different accounts as suggested by @marioevz code suggestion.
• Create the N different delegations for target T in a single tx (to save as much intrinsic gas as possible? But not sure this will have a limit reg tx size)
• Let T in the bullet above be parametrizable, i.e.: 0x00 for testing as many resets, and non-0x00 for testing real delegations.

[jsign]

Is this missing a defined parametrization?
(Edit: see also my message below)

[jsign]

Agree, but sounds it would only have effects for the first tx of the list. Starting with the second and further txs, the delegation will be considered a noop, no? So most tx won't be doing any real work.

I wonder if this test should probably:

• Try calculating the maximum number of delegations possible for gas_limit (and remove the iteration_count parameter).
• Create N different accounts as suggested by @marioevz code suggestion.
• Create the N different delegations for target T in a single tx (to save as much intrinsic gas as possible? But not sure this will have a limit reg tx size)
• Let T in the bullet above be parametrizable, i.e.: 0x00 for testing as many resets, and non-0x00 for testing real delegations.