feat(fw): add optional verify_sync flag to hive blockchain tests

[marioevz]

🗒️ Description

Adds an optional verify_sync flag for hive (or blockchain Engine API tests) to pick up and test a second client syncing to the first client.

Syncing is tricky to some clients and we actually need to send a full header via engine_newPayloadVN for some of them to start the sync process.

So this change also appends an empty block on top of the latest head of the test to use as syncing head.

🔗 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]

I like this a lot! 💯

Are you thinking that syncing should be specific to certain tests, after processing and setting the head post complex scenario, or applied to the end of all tests? Or even simple specific sync tests for each fork?

I tried running this modification for some the blob_txs tests, using your hive branch and it worked well! Personally it seems reasonable to do this for all tests.

One question arises for me: instead of creating a sync payload could we not use the last engine new payload in the test?

If we use a sync payload, when we integrate consume fully within EEST it should be straight forward enough to generate this payload on the fly.

[marioevz]

One question arises for me: instead of creating a sync payload could we not use the last engine new payload in the test?

The problem is that if the last engine payload is the one that triggers some special scenario you'd like to test under sync, and you provide this payload via the engine API, then we are not really testing syncing because the payload arrives in full via the engine api. Even in cases where we have more than one payload, we won't be testing syncing for the last one.

[spencer-tb]

LGTM - added the changelog.