upgrades: private state rollover during testnet

[erwanor]

Is your feature request related to a problem? Please describe.
In #2917, we were able to exercise the MVP upgrade functionality and test both: 1/ the coordination mechanism that node runners use to signal their intent to perform an upgrade 2/ the operational implications of doing so if the node runner chooses to, sharing context along the way.

Since then, we have added more functionality like checkpointing the genesis state, and performing full InitChain handshakes with CometBFT, completely pruning the consensus state and adhering to the recommended best-practice by the CometBFT team.

During the course of testnet 62, we should re-perform this test:

• with new tooling that incorporate @conorsch's feedback:
  • change the export command flag to --home
  • change the upgrade command flag to --upgrade-path
  • improve the command description
  • improve logging to explain the cause of halt when an upgrade height is reached
  • add an explainer message when a node refuses to restart because it the full node is in statis
• exercising a full checkpointed genesis and InitChain handshake
• upgrading a full node
• pd: test upgrading a validator node #3483
• pd: test bootstrapping a new node using an out-of-band snapshot #3482
• view: test syncing against an upgraded node #3485
• view: test syncing against a bootstrapped node #3484

Post 64:

• upgrades: make sure that relaying works across upgrades  #3577

[erwanor]

This is important but not urgent, and blocked on #3093 - targeting 63.

[conorsch]

Marking as blocked until #3093 is resolved; then we can pick this back up.

[conorsch]

pointing a 07 lightclient at the chain and making sure that it can validate across the upgrade boundary

This is the single remaining item tracked in the OP. However, it's blocked on #3506, so we've broken it out into its own ticket: #3577. Closing this as resolved.