Allow (ephemeral) Remotables or virtual objects as keys of (durable) weak collections

[mhofman]

What is the Problem Being Solved?

A non-durable object cannot currently be used as a key in a durable weak collection. This is a limitation we may be able to lift.

Weak collection keys are just recognizable, not reachable: you cannot obtain a reference from holding the weak collection, but you can get associated information if you hold a reference. Once an object is abandoned, the references in other vats remain valid: they can still "talk about" the object, but they can't "talk to" the object. Of course the exporting vat admits it lost its references to that object (or the kernel declares that on the vat's behalf when it gets upgraded).

However nothing precludes the other importing vats that still hold a reference to re-reintroduce a reference to the exporting vat. That object becomes an "imported presence" for that vat. That is all consistent because we cannot currently recognize the reference across upgrades.

But conceptually the ability to recognize a reference is orthogonal to the type of implementation of the reference (ephemeral, virtual, durable). A program may want store information about a reference it previously exported even though that reference is no longer linked to an implementation.

Description of the Design

Allow any remotable object reference to be used for any weak collection, regardless of their ephemeral/virtual/durable status.

Allocate a vref for any ephemeral object used in a weak collection, and monitor its ram pillar through a finalizer like if it was exported.

Use the vref of the object in the weak collection key

Change abandonExport so that it doesn't remove the clist entry entirely but instead keeps it if the vref is still recognizable

Change most allocatedByVat checks to support treating an unknown allocated object as an imported presence.

Security Considerations

Bugs stemming from confusion about the kind of object for previously exported references re-imported in later incarnations

Scaling Considerations

This should only require some extra disk bookkeeping, which is not considered a cost

Test Plan

TBD

Upgrade Considerations

Since this effectively enables new behavior that was previously forbidden, the only consideration is regarding contracts being able to express / detect that they need this feature before being deployed to a swingset/liveslots that may not implement this feature.

[warner]

Note to self: I think this is morally equivalent to having the kernel take over ownership of the "orphaned" object, at least for merely-virtual objects used as keys. Messages still go splat (the kernel isn't prepared to receive those messages), and the kernel still needs to retire the koid if/when the reachable count drops to zero, but now the original exporting vat is now more of an importing vat, so it needs to be told about the retirement too.

[warner]

We think we should not do this until we have a clear motivation, because it would be a difference in behavior between weak and strong (durable) collections that does not currently exist. @mhofman will look into why he filed this ticket and what problem it is trying to solve.