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):

• [x] #1811
• [x] #1805
• [x] #2959
• [x] #1807
• [x] #1798
• [x] #2917
• [x] #1809
• [x] #3004
• [x] #3451
• [x] #3307
• [x] #3081

Required for first chain upgrade:

• [x] #3841
• [x] #1812

Required for first chain migration:

• [x] https://github.com/penumbra-zone/penumbra/issues/3506
• [x] #3577

First chain upgrade

• [x] #4109

TODO

• [ ] https://github.com/penumbra-zone/penumbra/issues/2985
• [ ] #1806
• [x] #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).