allow bundlecaps in vatParameters

[warner]

What is the Problem Being Solved?

To enable contract upgrade, specifically to allow the version-2 vat code to perform #3062 Kind-behavior replacements during the very first crank of the new version's worker lifetime (before any inbound deliveries might reference those virtual objects), we need to change ZCF to:

• realize when it's running in version >= 2, rather than version 1
  • (the version-1 vat will receive a delivery instructing it what contract bundle to load, so we can make a API to fork a vat (create "zygote vat") #2268 zygote from the not-yet-specialized vat before that point)
• read vatParameters to learn the new contract bundlecap that is to be loaded
• use the bundlecap to retrieve the actual bundle
• importBundle() to load the contract code
• inform the contract code that an upgrade is in progress, and let it complete
  • the contract code can then reattach the virtual-object Kinds created by its predecessor

Currently, vatParameters is stored as a string in the kvStore, delivered to vat workers as they are started, and unpacked with a simple JSON.parse by liveslots.

To make this work, we need vatParameters to be able to hold caps, so the vat-upgrade code can pass a bundlecap for the new contract version to the upgraded ZCF vat. It isn't sufficient to use a bundleID, because one needs access to devices.bundle to synchronously convert that into a real bundle, and then we'd need to store devices.bundle in vatParameters. The need to fetch the bundle in the initial startup crank precludes a scheme which sends a message to vatAdmin to retrieve the bundle, since the response (dispatch.notify) could not be delivered until some future crank, which is too late.

Description of the Design

Here's what I've sketched out so far:

• the kvStore holds vNN.vatParameters as JSON.stringify(capdata), using krefs instead of vrefs
• vatKeeper.setVatParameters(capdata) is responsible for updating refcounts
  • so if version-1 references bundlecapA and version-2 references bundlecapB instead, setVatParameters(ver2capdata) will increfB and decref A (except that bundlecaps, like all device nodes, are currently immortal, and don't have refcounts; but all other objects should be tracked properly)
• the vat upgrade process uses vatKeeper.setVatParameters before launching the new vat

Past that, things get murky. As part of #2910 we're looking at changing the early steps of a vat worker into more messages that can be delivered (at the very least, buildRootObject must be called as part of a delivery, so there is a transcript writer waiting to record the syscalls it makes, and more importantly the responses that come back). If we go with dispatch.buildRootObject, then we can include vatParameters in the KernelDeliveryObject/VatDeliveryObject (using the vat translators to convert the kvStore's krefs into vrefs, populating the clist at the same time, remembering to make sure we get GC right). The transcript for this dispatch.buildRootObject delivery will include the D(bundlecap).getBundle() and it's gigantic response, which is ok for now but eventually we want to get that response out of the transcript, if/when we get tighter integration between liveslots, bundlecaps, and the Endo module loader.

Security Considerations

Not a lot; vatParameters is a communication pathway between the caller who asks for the vat to be created, and the root object of the new vat, and this just enables that pathway to include arbitrary objects.

In our #1848 vat/contract upgrade plan, vatParameters can be different for each version of a given vat, so it's provided by the vat-upgrading caller, in addition to the vat-creating caller. But vatParameters cannot be read back out from a vat, so it doesn't provide a direct communication pathway between creator and upgrader (unless facilitated by the child vat itself).

Test Plan

unit tests

[warner]

This depends on #2910 because that will turn vat-startup into a distinct delivery, going through a VatTranslator, making it a great place to deliver vatParameters that contain vrefs.

The create-vat run-queue event should change to move vatParameters out of options and into a separate place that is known to hold a kref-based capdata object. This capdata needs to be treated like a run-queue deliver event for GC refcounting purposes. The start-vat event should have a similar place for the vatParameters that are delivered to static vats (although there's no likely way for them to get slots, since their vatParameters only come from the config object, which is defined before any vats even exist).

[warner]

#4726 is a sub-task of this one, so I'm moving 2 of it's 3 story points to #4726

[warner]

#4588 will probably get closed as a side-effect of this one, when I change vatAdmin to use the new "device hooks" feature and we get to translate drefs to krefs.