Place "async" vat operations onto outbound queue

[mhofman]

What is the Problem Being Solved?

In the latest two run queue design, syscalls such as send, resolve and subscribe will be placed on a vat specific outbound queue as-is. Only when picked form the outbound queue, the syscalls will be fully processed, with corresponding reactions placed on other vat's inbound queues or kernel promise queues.

Description of the Design

As a first step #4638 added a single acceptance queue. Once send can be enqueue directly without going through the delivery queue (#4542), the send, resolve and subscribe syscall should be updated to not perform synchronous processing during the syscall, and instead delay that until plucked from the acceptance queue.

exit should be able to stay synchronous, so that a vat is immediately marked as terminated. In the future, the vat outbound queue will be drained even if the vat is marked as terminated.

dropImports and retireImports will stay no-ops (after translation), and the kernel ref counts should be sufficient to keep the kernel as a "holder" if needed, including for references still in the outbound queue.

retireExports and abandonExports can both keep updating kernel structures synchronously. In the case of retireExports, if the vat is well behaved, it should not have mentioned the retired object in a previous syscall. abandonExports simply does not make any send, resolve or subscribe calls.

Security Considerations

Ref counting must stay consistent. A message in the current acceptance and future outbound queues must keep incrementing ref counts. Moving from one queue to another should not change ref counting.

Test Plan

Add and update unit tests. Run loadgen as simple integration test.

[mhofman]

I just thought of a new comms / kernel test to add:

• vatA sends foo message to object on remote vat with result r1
• vatA sends bar message to r1 promise with result r2
• vatA sends baz message to r2 promise
• remote resolves r1 to object imported from vatA
  • comms reflects bar message back to kernel and vatA, reusing r2, this redirecting it
• kernel must move message baz from comms queue back to promise queue

There are also variations, like sending the initial message to a promise that vatA resolves after step 1 2 or 3, resulting in any some of those messages having to move from promise to decider queue, or straight to decider queue.

Some of these may not currently pipeline correctly because once in the promise queue, the message doesn't move back to the run-queue when the decider is updated.