proposal to execute Vaults null upgrade in test nets

[turadg]

What is the Problem Being Solved?

#7491 gives us confidence in the bulldozer upgrade from Pismo to Vaults.

When we've upgraded to Vaults we never want to have to bulldoze again. To have confidence in that we need to also perform upgrades of the Vaults release state.

Description of the Design

Tasks

Preview Give feedback

1. Inter Protocol contracts upgradable #5795
   Epic Inter-protocol vaults_triage +3
   
2. all vats that will be deployed in Vaults Release must be upgradable #6553
   10 of 10
   Epic Governance Inter-protocol contract-upgrade cosmic-swingset enhancement needs-design vaults_triage +8
   
3. feat: separate vaults launch from platform #7563
   force:integration +1
   
4. deployment test for restarting all restartable vats

Use https://github.com/Agoric/docker-upgrade-test/tree/main/upgrade-test-scripts to make a new upgrade handler.
It includes gov1,gov2,gov3 accounts.
Use agoric and agops CLI commands in the scripts, as an end user could. Maybe adapt https://github.com/Agoric/agoric-sdk/blob/master/packages/agoric-cli/test/agops-vaults-smoketest.sh

Consider adapting the bootstrapTests which specify behavior and expected results.

After bulldozer we have three different kind of upgrades:

1. Chain software (including SwingSet kernel, but doesn't change the contracts)
2. Liveslots (e.g. xsnap, more complicated)

• upgrade-by-replacement the contracts we've decided not to make durable
• we have documentation of this but won't fully test before release

3. Contracts (with CORE_EVAL)

This PR is about level 3. Figure out agd command to create the proposal. Call the Docker test harness's function to wait for it to complete.

Some vats we've decided will be upgrade by replacement. TBD whether to perform that replacement in this test.

Security Considerations

n/a

Scaling Considerations

n/a

Test Plan

• Add a test in https://github.com/Agoric/docker-upgrade-test/blob/main/Dockerfile that triggers a CORE_EVAL proposal (V+1 is just a contract upload and a CORE_EVAL, approved by BLD Stakers but not validators)
• Verify that product works with realistic state after restart of all vats
• Cover the Inter Protocol User Stories

What doesn't need to endure in Vaults release:

• invitations (one exception is coveredCall but that's not part of production)

[dckc]

Is this a dup of #6099? perhaps not... perhaps that one is an end-to-end test of one contract, where this one is less end-to-end but covers all vats/contracts

[turadg]

Exactly. 6099 is that a contract can be upgraded on a running chain. That can be a local chain. Ideally it would be in CI.

This is to do the real deal on testnet, after a bulldoze.