"Leak" of unwatched subscribed promises across upgrades

[mhofman]

What is the Problem Being Solved?

In incarnation 1, a vat may perform an eventual send or otherwise receive a promise to which liveslots will automatically subscribe to. The contract may not watch that promise (which is often, but not always a sign of a bug, see #9771). The subscription remains across vat upgrade, however the new incarnation would be unable to do anything with the resolution if/when it receives it if the promise wasn't watched. This results in a sort of leak of the clist of the vat until the promise gets resolved by the external decider, even though the vat has provably no interest in this resolution. This is somewhat a special case of the vat not being interested in a promise it receives because the user code drops the promise (#8469), but with actual knowledge that the user code is not interested because it doesn't even know about the promise anymore.

Description of the Design

Possibly a variation of #9771 where the kernel/the upgraded vat unsubscribes from non watched promises during upgrades.

Security Considerations

Only unwatched promises must be affected

Scaling Considerations

How to track these unwatched promises across upgrades

Test Plan

Reproduce case described in problem solved and verify promise is removed from clist after upgrade

Upgrade Considerations

Likely requires changes to liveslots, which means it might only affect promises created after liveslots is upgraded.

[warner]

We're making this low-priority, because the cost is low: some extra DB space for the c-list entries, and some wasted (but tiny) dispatch.notify if/when they resolve. To fix this we'll need the kernel to know whether a subscription is "durable" or not (durable promise watcher means durable subscription), so non-durable subscriptions can be unsubscribed by the kernel on behalf of the vat during upgade.