promise that fires once a bundle is installed

[warner]

What is the Problem Being Solved?

#3272 (comment) pointed out the utility of allowing Zoe to wait for a particular bundleID to be installed. It would allow a governance-gated zoe.install to happen with just a single (small) governance vote, even though the (large) bundle gets installed to the chain after the vote passes.

To accomplish this, we need something that can return a Promise, something with a signature of xxx(bundleID).then(bundlecap => stuff..).

If raw devices could return promises, we could use D(devices.bundle).waitForBundlecap(bundleID). I didn't include full promise support in #4419 , so I'm not sure how much additional work it would require.

Another option is to add a companion vat, like we do for timer and vat-admin. The bundle device would push a message to the bundle vat that says "bundleID XYZ has been installed", and the vat would resolve the promise. The userspace-visible invocation would then be E(vats.bundle).waitForBundlecap(bundleID). If we went that way, it'd be tempting to move the rest of the API over to the vat as well, but I added raw devices to avoid that sort of thing.

In either case, the device code (which can push messages onto the run queue, and knows who wants to be notified) needs to be invoked when the bundle is installed. But the external API is currently controller.validateAndInstallBundle(), on the controller. This highlights the close relationship between the bundle device and the controller: currently the controller writes to the DB, and the device (using kernel-provided endowments) can read from the DB. But adding a notification interface means that these two points want to talk to each other.

Let's see, for the mailbox device, external callers interact with the device's outer/input API surface, rather than going through the controller (neither the kernel nor the controller know anything special about the mailbox device). I'd like bundles to be more "batteries included", though.

Ok, so I think I'm cool with having controller.validateAndInstallBundle() invoking some device code so it can push run-queue things. I still need to think about where the promise should come from.

Description of the Design

Security Considerations

Someone who has access to the bundle device (or whatever provides the promises) could incur a storage burden by asking for a whole bunch of nonsense bundleIDs that will never get installed. We might fix this by having a single "some bundles have been installed" notifier, rather than tracking a separate thing per bundleID.

Test Plan

unit tests

[warner]

#4523 would make it easier to add a companion vat. That would change the overall bundles API to:

• E(vats.bundles).getBundlecap(bundleID) -> Promise<bundlecap>
• E(vats.bundles).getNamedBundlecap(bundleName) -> Promise<bundlecap>
• D(bundlecap).getBundleID() -> bundleID
• D(bundlecap).getBundle() -> bundle

If we gave vats.vatAdmin access to vats.bundles, then E(vats.vatAdmin).createNamedVat(bundleName) could maybe stick around. (Currently it uses a funky endowment that I'd like to remove, and if so I'd remove createNamedVat and require callers to go through getNamedBundlecap first).

The storage burden is still an issue. And maybe we want two separate APIs: one "wait forever until bundle is installed", and a second that rejects the promise if the bundle isn't already installed. And/or a query API.

Internally, E(vats.bundles).initialize({ devices: bundles }) would give devices.bundles a reference to a private object that should be notified when a new bundle is installed. vats.bundles would use the same D(devices.bundles).getBundleCap(bundleID) as before, but the signature would change to -> bundleID | undefined instead of throwing an error when the bundle was not installed. devices.bundles would be given an endowment that allows it to register a callback with the kernel. kernel.installBundle() would invoke this callback (with bundleID) after the bundle was safely installed in the kernelKeeper.

[warner]

I think I'm going to address this by having vatAdmin re-export the bundle functionality. This will get the same API described for vats.bundles above, but should allow Zoe to do its job with only access to vatAdminService, which will reduce the changes we need to make in external dapp repositories.

The downside is that anyone who calls createVatAdminService() will need to change their calls and provide devices.bundle in addition to the existing devices.vatAdmin. (The need for this could be removed with something like #4523).