feat(fixtures,specs,types): Verify address collisions during pre-alloc grouping phase

[marioevz]

🗒️ Description

Detects different tests writing different accounts to the same address in the pre-allocation in the same group, and fails early if that's the case.

It works by the following procedure:

• When the test function finishes writing to the test's pre and the grouping logic tries to flush the pre into the existing grouping's pre, it first collects keys existing in both allocations.
• If there is an address that is present in both allocations, the accounts are compared an expected to be exactly equal.
• If the accounts are equal, the grouping continues: This works because the pre-allocation is located in the genesis and we revert to genesis during consume engine-x, so even though the two tests access and (potentially) modify the same account, when the revert to genesis happens the account also reverts to the original state expected by both tests.
• If no collisions were detected in any of the tests assigned to the worker, the grouped pre-allocation is saved to file.
• If a worker attempts to write to file and a group file is already there (two tests in different workers using the same grouping for example), when the files are merged the collision detection is also enabled.
• The phase-1 of the pre-alloc grouping fails if the collision is detected at any point.

This is helpful to debug static tests and quickly detect when two static tests with same hard-coded addresses interfere with each other.

🔗 Related Issues or PRs

N/A.

✅ Checklist

• All: Ran fast tox checks to avoid unnecessary CI fails, see also Code Standards and Enabling Pre-commit Checks:

  uvx --with=tox-uv tox -e lint,typecheck,spellcheck,markdownlint

• All: PR title adheres to the repo standard - it will be used as the squash commit message and should start type(scope):.
• All: Considered adding an entry to CHANGELOG.md.
• All: Considered updating the online docs in the ./docs/ directory.
• All: Set appropriate labels for the changes (only maintainers can apply labels).

[felix314159]

Can you provide an example command (ideally a minimal / fast one) that we can use to see the different behavior (before this PR vs after the PR)?

[marioevz]

Can you provide an example command (ideally a minimal / fast one) that we can use to see the different behavior (before this PR vs after the PR)?

You can try this command:

uv run fill --clean --fork=Cancun --fill-static-tests --generate-pre-alloc-groups tests/static/state_tests/Shanghai/stEIP3855_push0/ -x

Before and after this PR: before it fails until the second phase, and after it fails during the first phase because it detects the collision early.