stopVat should only reject promises and abandon non-durables

[warner]

What is the Problem Being Solved?

A remaining part of #1848 is to reduce the amount of work we do during stopVat to a bare minimum. We're concerned that stopVat in vats with large accumulated data will take too long, effectively making it impossible to upgrade such vats (I expect to see consensus problems if it takes more than ~30s).

The bare minimum is:

• reject all pending promises (stop-vat.js: rejectAllPromises())
• abandon all non-durable merely-virtual exports (abandonExports())

This will leave data in the DB that is no longer reachable:

• merely-virtual objects
• merely-virtual collections

Those objects might maintain refcounts on durable data and imports, which would otherwise be dropped.

We think this is acceptable for MN-1, because:

• 1: we expect our early contract developers will mostly use durable data, rather than merely-virtual data
  • partly because they need it for upgrade, partly because of this stopVat cleanup limitation
• 2: we believe we have enough of an index to allow startVat() (in a new version of liveslots) to perform this cleanup properly, spread out over multiple calls to bringOutYourDead()
  • add index of collections, improve stopVat deletion code #5090 has some details on the index

This is a compromise, of course: we would prefer to delete everything, completely and precisely, during stopVat. We'd really prefer for the kernel to delete everything, but I don't think our data structures make that easy to do without some excessive coupling/mututal-understanding between liveslots and the kernel.

Description of the Design

Change stop-vat.js to only call rejectAllPromises() and abandonExports().

Eyeball the current virtual-kind index DB keys and convince ourselves they'll be enough to perform the deletion in a later version.

Security Considerations

Shouldn't be any: abandoning the virtuals should make them inaccessible from the outside world, and the existing prohibition on durable objects/collections holding non-durable children will make them inaccessible from the new version as well.

This does allow a vat to accumulate more DB space over time, by creating a bunch of virtuals and then upgrading. But I think the threat is of the same magnitude as the existing ability to create virtuals within a single version, independent of upgrade.

Test Plan

There's already a test (test/upgrade/test-upgrade.js) which creates an extensive set of data, performs an upgrade, then looks to see what was deleted and what still remains. We just need to modify that test to expect more things to remain.