liveslots finalizers do syscall.dropImport, remove safety pins

[warner]

What is the Problem Being Solved?

The vat-side delivery of GC events is driven by FinalizationRegistry callbacks firing at end-of-crank, after GC has been provoked and finalizers have had a chance to run. This populates the "dead set", which is then scanned to see what items are safe to drop, which can be retired, and what needs to be processed further.

GC as a whole will start saving RAM when:

• the liveslots "safety pins" are removed, allowing objects to be collected (this ticket)
• liveslots responds to finalizers and emits dropImport at the right time (this ticket)
• the kernel processes refcounts and emits dispatch.dropExport
• the kernel acts upon syscall.dropImport by decrementing refcounts
• liveslots acts upon dispatch.dropExport (by dropping its strongref to the Remotable)

part of #3106

Description of the Design

• change the liveslots dispatch function.
  • currently it waits for the userspace to become idle, then returns
  • instead, when userspace becomes idle, it will use gcAndFinalize to provoke a GC sweep (using some engine-specific means) and wait long enough for finalizers to run
  • then processDeadSet() will be called
• finalizers already collect dead vrefs in the dead set, no change needed there
• processDeadSet must examine each now-un-strong-referenced vref and decide what to do:
  • for Presences, if the vref is not reachable by the virtual object manager (VOM should track Presence vrefs used in virtualized data, to inhibit dropImport #3133), can be sent to dropImport
    • later, we'll also ask the VOM if the vref is in use as a key of a Weak Map/Set, and thus still recognizable, and if not, also send it to retireImport. but not today.
  • Representatives are exports, and for now are ignored
  • Remotables are sent to syscall.retireExport, since once the Remotable is gone, nobody can ever reach it again

Dependencies

It won't be safe to remove the safety pins until everything inside the vat is holding on to the objects they're supposed to. This means:

• Virtual objects should use WeakRefs to enable === #1968 Representatives are unique (only one in memory at a time, === works)
• replace userspace WeakMap/WeakSet with vref-aware versions #2993 WeakMap/WeakSet are vref-aware for keys
  • until both are true, if liveslots dropped the Representative, its reincarnation would not be a suitable replacement as a Map/Set key
• virtual object manager must retain strongref to Remotables in virtualized data #3132 the VOM must hold a strong reference to any Remotable used in virtualized data

Test Plan

Unit tests which create a liveslots instance (without a kernel) whose userspace code creates and unreferences various objects. The test will observe the syscalls it makes to assert they are the expected ones.