perform bundle+install during chain-software upgrade

[warner]

What is the Problem Being Solved?

To upgrade zoe and/or ZCF (or any number of core contracts, like vaultManager), we'll need a new bundle for each. This bundle must be created from individual source files, then somehow delivered to all validators, then somehow installed into the kernel bundle table (controller.validateAndInstallBundle). After that happens, we can core-eval code that references the BundleID hash.

Using cosmos transactions to deliver a bundle to the chain is expensive, because the bundles are so large (3-5MB), so the txn fees are high (we also use these fees to deter abuse). Eventually, we'll certainly need to make this an option, but at this early stage of the chain, when everything is so tightly controlled (a validator vote is required to install or instantiate any new contracts), we can piggyback the new bundles as part of the chain-software upgrade.

Description of the Design

@michaelfig 's basic idea is that when the chain software is upgraded, the new version's upgrade handler (in Go) will deliver a special message to the JS side, that says "please look on disk at pathname XYZ, run bundleSource() on that entry point, assert that the resulting bundleID is ABC, then call controller.validateAndInstalBundle() with the bundle". We effectively include the new zoe/ZCF/etc as part of the agoric-sdk tree used in the upgraded node, in pre-bundling form. This doesn't cost any txn fees.

@michaelfig is also considering having JS code run at this point to perform a core-eval and actually use the new bundles (e.g. upgrade the Zoe vat to a new bundle, or tell Zoe to start using a new ZCF bundle). But this ticket is just about the ability to bundle the code on disk during an upgrade, and install those bundles.

Security Considerations

No new ones, because upgrading chain software allows changing any aspect of execution. Obviously, at some point we want to be able to upgrade a contract without also using the authority to modify the entire node, but doing this bundling+installing is not adding any new authority to the upgrade process.

The zoe/ZCF/etc code in the agoric-sdk is slightly easier to read and audit than a separately bundled and (txn-driven) installed copy, since our tooling for getting from a bundleID back to the source code is not well developed. So piggybacking the bundling process as part of the upgrade is probably better from a reviewability/legibility point of view.

Scaling Considerations

This will slow down the upgrade process slightly: it takes a few seconds to bundle each component. But it's a lot cheaper (and results in a lot less extra chain state) than sending bundles in as a txn would take.

Test Plan

Not sure, hoping @michaelfig has some ideas.

[JimLarson]

Implemented the Cosmos side in #7994 by passing the upgrade Plan as an optional extra field plan in the AG_COSMOS_INIT message. The info string field of the plan will, by convention, be a JSON-serialized object to which we can add new fields for SwingSet to interpret. However, no SwingSet-side interpretation code has been added yet.

[JimLarson]

See #8095