refactor vat dispatch()

[warner]

What is the Problem Being Solved?

As preparation for the second half of #2660 , I want to refactor the way vat supervisors invoke the liveslots/comms/raw-vat dispatch object.

Originally, dispatch was defined to contain four methods: deliver (for message delivery), and notifyFulfillToPresence/notifyFulfillToData/notifyReject (for promise resolution). When @FUDCo cleaned up promise resolution (and we moved to batch resolutions), the last three were consolidated into a single notify method, leaving us with two: deliver and notify. #2653 makes that three: deliver, notify, dropExports.

Originally, vats were defined by a dispatch object with those methods, wrapped around a syscall object with a half-dozen or so methods (which have changed over time as well, and currently support: send, callNow, subscribe, resolve, exit, vatstoreGet, vatstoreSet, vatstoreDelete, and dropImports via #2635). The return value of the dispatch methods are mostly ignored: if it throws, or returns a Promise which rejects, we will log the error, but we don't treat that as evidence that the delivery failed. The vat dispatch is not considered "done" until the engine's promise queue is empty: the code which called dispatch methods would return a separate Promise that isn't resolved until a pre-prepared setImmediate callback runs. This ensures that the vat code (at this point, everything beyond dispatch) cannot retain agency after the kernel believes the crank to be done.

Then, when we moved from running all vats locally, to different "manager types" and the manger/supervisor split, we introduced the "VatDeliveryObject": a serializable short array containing a command to be sent to a vat. The kernel-side code finds the target vat's manager and invokes manager.deliver(vatDelivery), which is expected to return a Promise that fires with a vatDeliveryResult (just a two-element array, ['ok'] or ['error', message]). The manager does whatever local or remote interaction it needs to fulfill this contract.

On the worker side (which might be the same process as the kernel, a thread, or a child process), some workertype-specific supervisor code receives and reconstructs the VatDeliveryObject and figures out how to invoke the vat's dispatch method. This supervisor is responsible for waiting until the vat is quiescent. The supervisor is also where we look at the metering situation and decide whether the crank failed because it exceeded a limit of some sort.

To support #2660, I want to change dispatch to return a Promise, and have liveslots take on responsibility for waiting for the user-level vat code to become quiescent (it will need a waitUntilQuiescent endowment for that). Meter checks are still the responsibility of the supervisor (both because the xsnap supervisor is written in C and only C has access to the metering data, and because then any time spent in liveslots is still subject to metering).

I'm thinking that dispatch should also be changed to a function that accepts a vatDeliveryObject, instead of exposing three separate methods. This would reduce some of the parsing code in each supervisor, and remove some duplication in the code that implements those methods.