Burn-in - Automate pre-release - upgrade existing instances

[jflo]

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

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:

• Upgrade existing instances to the new build, like most users would. 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 continue to follow the head of their network, within established attestation distance.
• Confirm that block proposals are still executed, and produce profitable blocks relative to network conditions.
• Confirm that block execution time, peer acquisition, cpu/memory/disk consumption are within tolerances of established baselines.

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

[github-actions]

This issue is stale because it has been open for 6 months with no activity.