Release tracking issue: Network upgrades

[erwanor]

Performing network upgrades on a Penumbra network

This ticket tracks the "network upgrades" epic, which consist in adding the ability for testnets to persist state across new Penumbra major releases via an "upgrade mechanism", or a migration.

Design considerations:

The original design document written by @avahowell @hdevalence, and @erwanor lives here:
https://hackmd.io/@qECaDUmnQJO3OnZwlRPThQ/rkXlh0xuo

An additional field guide manual exists: https://hackmd.io/@U47bTB1sSym1rzNSov3h6Q/upgrades_field_manual which comes in handy to actually exercise the process

TODO (Basic Upgrade Support):

• Add semantic version of domain types / protos #1811
• upgrades: create protos in the governance module #1805
• chain: implement upgrade halts #2959
• pd: export state snapshots to disk #1807
• Fix chain halt logic so that the halt occurs after ABCI commit phase #1798
• upgrades: testnet rollover between 60 and a private fork #2917
• upgrades: add support for checkpointing in AppState #1809
• upgrades: InitChain handshake with comet #3004
• pd: index cometbft block data  #3451
• penumbra: rethink our versioning strategy #3307
• upgrades: private state rollover during testnet #3081

Required for first chain upgrade:

• pd: support state tarball for joining nodes #3841
• upgrades: create a template guide  #1812

Required for first chain migration:

• upgrades: revisit our migration strategy #3506
• upgrades: make sure that relaying works across upgrades  #3577

First chain upgrade

• upgrades: perform a chain migration for #4084 #4109

TODO

• ibc: add support for host chain upgrades #2985
• pd: implement JMT pruning #1806
• ibc: allow governance to amend counterparty clients #3024

Sketch design document: https://hackmd.io/@qECaDUmnQJO3OnZwlRPThQ/rkXlh0xuo

[conorsch]

Discussed at sprint planning. Originally, we'd hoped to perform an upgrade between 59 and 60, but given that a lot of the core functionality hasn't landed yet, 60 -> 61 is more likely. During 59 release announcement, we should engage the validator community and telegraph our intention to involve them in a coordinated chain upgrade.

[erwanor]

The first deliverable for this stream of work is performing a "no-op" upgrade i.e. a network upgrade that doesn't actually require any state migration at all. This will let us test the main logic flow (proposal -> enactment -> halt -> new start) without having to write any upgrade specific logic and this can be done on a devnet. Once this is done, we can circle back on doing a persistent testnet opportunistically (tracked by #2917)

[erwanor]

In the course of #3081, we were able to confirm that users are able to synchronize their private state across the upgrade boundary and perform swaps. The next step for upgrades is transitioning from biweekly devnets to longer lived ("persistent") testnets.

The current target for the first upgrade is Testnet 65 -> Testnet 66. This will require reworking our migration strategy (#3506) and then test that relaying does not require any maintenance when we perform non-lightclient-breaking upgrades (#3577).