Burn-in - Automate pre-release - new nodes

[jflo]

As a besu dev, I would like a consistent, low-friction, high signal process to confirm a potential release candidate is good enough for brand new Ethereum users.

An RC (release candidate) can be defined by any git tag or sha, allowing the process to be used with maximum flexibility.

When we burn-in / regression test an RC, we do the following:

Deploy brand new client instances with no existing data, which need to synchronize with their respective network. These existing nodes are currently running on Consensys managed infrastructure. They need to account for the sepolia, holesky, and mainnet networks, and each network should be tested against all consensus layer clients.

• Confirm that clients synchronize to the head of their network, without need for manual intervention.
• Confirm that time taken to reach head is within established tolerances of baselines, per network.
• Confirm that clients establish peers and maintain them within established tolerances of baselines.
• Once through the sync process, should test for regressions defined in #6638

This is a very manual process, which should be automated.

[macfarla]

Including a regular fullsync of nodes during the testing cycle would be good. Some nasty bugs e.g. self destruct Bonsai bug were caught by doing fullsync testing on testnets.