feat(kernel): Support liveslots distributed garbage collection

[sirtimid]

Closes: #329

• Add handlers for syscall delivery messages related to distributed garbage collection:
  • dropImports: Vat tells kernel it no longer needs certain imported references
  • retireImports: Vat acknowledges retirement of imports and promises not to use them again
  • retireExports: Vat tells kernel it's retiring certain exported objects
  • abandonExports: Vat tells kernel it's abandoning exported objects (even if they are live)
• Add incrementRefCount and decrementRefCount functions to manage reference counts for kernel objects and promises
• Extend deleteClistEntry to handle reachability flags and reference counting
• impement both "reachable" and "recognizable" refcounts on all kernel objects
• update these refcounts during clist additions/removals
• track the refcounts that touch zero, add them to a new maybeFreeKrefs ephemeral set
• process that set at end-of-delivery, to see what GC actions should be scheduled
• add those actions to a new durable GC Actions set (in the kernelDB)
• scan the pending actions before each new delivery, to prioritize GC work
• deliver the highest-priority non-negated GC Action to the appropriate vat
• restrucure ported GC code for better structure and organization
• update all unit tests as necessary, add new ones

[FUDCo]

I'm not completely wild about this refactor of kernel-store. To be clear: I think breaking it apart into more manageably sized pieces is well motivated, given that it suffered a bit too much from having fallen into the big-ball-of-mud pattern (which it acquired by way of its SwingSet heritage, which in turn got that way because it just growed). Moreover, I think the partitioning of functionality here seems mostly sensible.

However, given that its job is simply wrapping various bits of higher-level, kernel-specific functionality around a single underlying (and fairly stupid) key/value store, I'm not comfortable characterizing the various sub-groupings of function as "stores" in their own right (though doing that arguably might make sense in a world where we implement more of those bits of functionality directly in the database with their own individualized tables, schemata, and prepared statements, and maybe that's an idea we should talk about -- a refactoring like this might make sense as a precursor to moving things in that direction). While calling them "stores" might actually just be a naming quibble, reifying each of them as its own object (with accompanying factory function) feels like a pretty heavy weight approach, especially given the fairly complicated graph of dependencies between them -- I'm betting that getting the order-of-initialization logic right for them all was a bit of work. Given those cross dependencies, I'm concerned that the whole thing may be fairly brittle under maintenance. On top of this, the big-ball-of-mud API is still retained in the end because that's how remains exposed to the rest of the kernel

In short, my intuition is that if you're going to refactor the kernel store, you should go all the way (perhaps exposing the "kernel store" as an explicit bag of sub-functionality groups), otherwise I'm not sure it pays for itself.

[sirtimid]

Thanks! That’s actually great to hear because the main reason I kept the factory-based approach was to avoid deviating too much from the existing pattern. I was already aware that it introduces order-of-initialization challenges and I had considered refining it further to align more closely with the overall code style. I held back from making major changes in this pass but now that it's in this state I think it’s clear that a more thorough refactor would be worthwhile.

[sirtimid]

@FUDCo Check it out e00a14b

[FUDCo]

This refactor is still going to collide with critical bug fixes in #448. I'd be much more comfortable if the kernel store refactor was separated into its own PR so that we can land the GC stuff now.

[sirtimid]

Ok I've reverted the refactor and will do it on a separate PR after #448 is merged. I will also add the unit tests on that PR because it will be a big hustle to adjust them for the one file now. Added a task to track it

[FUDCo]

OK. Let's all plug our ears and wait for the kaboom!