kernel storage scalability

[warner]

The Swingset kernel must be able to handle millions of objects and messages. It should also be able to restart from saved state in a reasonable amount of time.

As described in https://github.com/Agoric/agoric-sdk/issues/54#issuecomment-567262976 , we have roughly 8 tables that will grow with the number of objects and/or messages that have ever been seen. This ticket tracks our progress towards moving all of these to disk, so our RAM footprint is proportional to the size of a single message, rather than the number of all objects that have ever been created (i.e. "1Z").

• [ ] #512 the Comms Vat has a bunch of c-lists (one per remote machine), and union of all their entries point to 1Z object imports (o-1234)
• [ ] #54 #511 the Comms Vat's transcript contains 1Z messages, whose earlier delivery is what created those entries
• [ ] #54 the kernel-side c-list for the Comms Vat has 1Z entries mapping o-1234 to kernel objects like ko5678
• [ ] #54 the kernel object table tracks the owner of 1Z objects: ko5678 -> vat[issuer]
• [ ] #54 the kernel-side c-list for the Issuer Vat has 1Z entries mapping ko5678 to vat exports like o+9876
• [ ] #455 #512 the Issuer Vat, in it's current transcript-based orthogonal-persistent form, has a javascript Map with 1Z entries that map vat exports like o+9876 to javascript Purse/Payment objects with various methods on them
• [ ] #455 #512 the Issuer Vat has 1Z Purse/Payment objects
• [ ] #54 #511 the Issuer Vat's transcript contains the 1Z messages that originally created and retrieved Purses/Payments

The kernel-side c-lists and tables will be addressed by #254 (switching to a HostDB at all) and #54, when the in-memory HostDB is replaced by a proper (synchronous) on-disk database. This will also take care of the storage space for the transcripts. However restart will still have to replay all of those messages, so it won't run "in a reasonable amount of time" until we also have heap snapshots (#511).

The vat-side Presences/Purses and Maps (Presence to/from import IDs, and Object to/from export IDs) may be addressed by #455 (hierarchical object IDs), but also require some form of not-yet-invented bulk storage API (#512) by which vats can ask the kernel (and/or some device) to hold key/value tables on disk.

The Comms Vat's c-lists will require that same bulk-storage API (#512).

[warner]

In addition to reducing the table entries that track callable objects, we must also delete entries for Promises that have been resolved. #675 tracks this one.