add no-op syscall.dropImports to vat-kernel protocol

[warner]

What is the Problem Being Solved?

The first steps of the #2615 GC task includes the creation of a syscall.dropImports(vrefs), which accepts a list of vat references (e.g. o-12) that the vat has stopped using. Eventually this will be triggered by FinalizationRegistry callbacks at end-of-crank. Eventually the kernel will process the dropImports by decrementing refcounts and releasing other objects. But for now, merely having a no-op syscall will be sufficient to allow both of those future steps to be developed in parallel.

The vrefs will be limited to object IDs for now, I don't think we have a clear understanding of how we could drop unreferenced unresolved promises correctly, and the GC problem is less severe for Promises because most of them get resolved sooner or later, and we already have a working mechanism for retiring and releasing resolved promise IDs.

Description of the Design

syscall.dropImports([vrefs])

• dropImports can be called at any time during the crank. Normal vats will only call it at end-of-crank (driven by liveslots checking the finalizers), but the comms vat will call it in response to many inbound comms.dropImport messages (Cope with asynchrony in remote retirement of promise IDs #2509 (comment)) that are freely interleaved with other syscalls.
• All vrefs must be o-NN (imports), not o+NN (exports): we'll use a different mechanism for revoke a Remotable #2070 object revocation, because those will need an Error to go along with each
• All vrefs must be previously imported: they must already be in the c-list. We may skip this check while the syscall is in the no-op stage, but eventually it will be a vat-fatal error to drop something that wasn't previously imported (or drop something twice without an intervening new import)
• Once dropped, the vat must never reference the vref again, unless the kernel references it first (causing a re-import). In general we'll have the kernel allocate new vrefs and never trigger a re-import, but while the syscall is a no-op, the kernel won't be deleting the c-list entry and thus re-delivery of the same object will look exactly like a re-import of the same ID.
• Once dropped, the vat is not expected to remember the vref: if the kernel does re-reference the ID, the vat is allowed (and expected) to create a brand new Presence to represent the new import.

Security Considerations

Test Plan

I intend to write unit tests to assert that this syscall can be made from all our vat runners. Since we decided the XS vat runner didn't need to support setup-based "raw vats", I need a way to reliably trigger dropImports from user-level vat code. When we get the vat-side finalizers (and explicit gc() invocation) working, this will be as simple as not retaining the imported Presence, but until that point we need some other way to trigger dropImports.

I propose to add a vatPowers.disavow(presence) function, disabled by default, that can trigger a dropImports. #2636
has the writeup of that proposal.

[warner]

In my branch, syscall.dropImports is slightly more than a no-op: it deletes the c-list entry on the importing vat. This will call decrementRefCount() on the kernel object-id (the koid), but that function does not currently do anything in response to objects being decref-ed, only promises.

My vatTranslator function deletes the c-list entries while it is holding both vref and kref, and then delivers the set of krefs to the kernelSyscall dropImports function. My plan is for the latter to use the set of newly-dereferenced krefs as the starting point of a "did we decrement to zero?" check, to GC any non-cycles that just became dereferenced. But that might change as we figure out the refcount management part of the GC task.

[warner]

Note that dropImports is currently recorded in the transcript. That will need to change when we have vats emitting it in reaction to finalizers, for the non-consensus mode (i.e. ag-solo). Once that becomes a possibility, we should not require that transcript replays emit the same dropImports syscalls as the original did, which means we should probably omit them from the transcript altogether.