Comms vat promise resolution handling needs to selectively deliver auxiliary resolves

[FUDCo]

The changes to the comms vat landed as part of #2242 treat the collection of promises contained in a notify message as subsidiary to the first promise in the collection, which they are at the point of origination. However, since the comms vat fronts for possible multiple swingsets elsewhere, it may be possible that there are swingsets subscribed to subsidiary promises that are not subscribed to the primary promise. This means that the bundle may need to be taken apart and repackaged in different subsets of conveyance to different remotes. We need to figure out if this is necessary, and if so figure out how to do it, then do it.

[warner]

Hm, maybe the right approach is for the comms vat to:

• process the incoming notify bundle, update the comms promise table status for each, collect a list of (remoteID, localPromiseID) notifications that need to be sent out (remembering that one of the remoteID might be the kernel)
• extract the set of remoteIDs from that list, loop over it
  • find all the promiseIDs that this particular remoteID needs to know about
  • use that as the initial contents of the outgoing bundle
  • examine all members of the bundle for resolved data that contains more resolved promises, add them, just like we do in the kernel, and will do in liveslots
  • loop until nothing is left
  • translate all local refs (lrefs) in the bundle into remote-refs (rrefs)
  • delete the c-list entries for all the promises resolved (from this remotes c-list only)
  • send the bundle

Ideally this should mirror what the kernel does. The kernel does its resolutions spread out over multiple cranks (at least one per target vat) but in theory it could do the same sort of batching/preparation as outlined above.

This does raise a question for future refactorors: given how similar the comms vat algorithm must be to the kernel algorithm, should we try to factor out that logic into some shared code? Or should the kernel absorb the comms vat and do its job directly? The big difference is that local cranks are immediate (specifically, no syscalls are emitted outside of a crank, so the kernel doesn't need to worry about messages passing like ships in the night), whereas remote systems are most decidedly asynchronous and all table-deallocation steps must prepare for crossing messages.

[FUDCo]

Closed by #2752