refactor deliverAndLogToVat kernel code

[warner]

What is the Problem Being Solved?

To make the implementation of #1848 vat upgrade easier, I'd like to refactor the way kernel.js processes deliveries to vats. We currently pull items off the various run queues (GC Actions, BringOutYourDead, and the main run-queue) and send them each through processDeliveryMessage. This fans out into several different helpers:

flowchart LR
processDeliveryMessage --send--> deliverToTarget
deliverToTarget --> deliverToVat
deliverToTarget --> resolveToError
deliverToTarget --> queuePending["queue on unresolved promise"]
deliverToVat --> deliverAndLogToVat
deliverToVat --> resolveToError
processDeliveryMessage --notify--> processNotify
processNotify --> deliverAndLogToVat
processDeliveryMessage --create-vat--> processCreateVat
processDeliveryMessage --start-vat--> processStartVat
processStartVat --> deliverAndLogToVat
processDeliveryMessage --update-vat--> processUpgradeVat
processDeliveryMessage --reap--> processBringOutYourDead
processBringOutYourDead --> deliverAndLogToVat
processDeliveryMessage --gc-action--> procesGCMessage
processGCMessage --> deliverAndLogToVat

Loading

At the end of processDeliveryMessage, we check terminationTrigger to see if "the" vat died during the delivery, and then unwind cranks or do other cleanup work if necessary. Most of the helper functions return a policyInput, and there's not a great way to report an error back. Errors or other delivery status might include:

• syscall violation (vat should be terminated or paused, crank unwound)
• worker died from a hard metering limit (vat should be terminated or paused, crank unwound)
• vat asked to terminate (delete vat state, notify followers, commit crank)

Once the delivery status is known, the caller should handle metering: deduct computrons, check for underflow, either terminate or pause the vat.

After that point, we might know what to do with the worker. If the vat was terminated, we should definitely stop the worker. If something went wrong and we decide to pause the vat, we should stop the worker (and tell vat-warehouse to refrain from saving a heap snapshot, so if/when we resume the vat, we'll start from a new worker that wakes up just before the half-finished delivery).

I know that vat-upgrade will need to be handled by the following sequence:

• deliver a BOYD (to flush any durable-object caches) and wait for it to complete successfully
  • if this fails, the vat has the same problems as if a BOYD had failed earlier
  • it's ok if we commit the crank at this point, but we don't have to
  • vat-warehouse does not need to record a heap snapshot, we're throwing them away anyways
• instruct vat-warehouse to discard the worker, delete the transcript
• change the vat's source-code record and options to point to the new BundleID and VatParameters
• deliver a startVat and wait for it to complete successfully
  • this will cause vat-warehouse to bring the vat online, knowing about the new bundle but not yet loading it
  • then dispatch.startVat causes the bundle to be evaluated (possibly failing, if top-level code is broken), and buildRootObject() (or upgrade() or whatever design better vat-facing upgrade protocol (buildRootObject()? upgrade()?) #4382 uses) gets called (possibly failing, or failing to reconnect/honor all of the previous version's obligations and Kinds)
  • if startVat is successful, notify the upgrade parent of the success, and commit the crank
  • if it fails, unwind the whole crank (reverting all the state changes), tell VW to discard the worker, notify the upgrade parent of the failure
    • this should reset back to the previous version, allowing the next message to the not-upgraded vat to bring the old version online (from the previous heap snapshot, and partial transcript)

So I want processVatUpgrade to be able to perform two deliveries. And I need a place for code to tell VW to discard a worker.

Description of the Design

TBD

Security Considerations

Test Plan