comms doesn't handle retired promise IDs properly

[warner]

Describe the bug

While building more comprehensive tests for #1404 I found more problems in the comms vat's handling of resolved promises. Our current rule is that when either the kernel or the vat resolves a promise, both sides will retire the promise ID, in the hopes of GCing data sooner. Regular vats implement this in liveslots, but the comms vat is lower level than that and does not use liveslots. The comms vat doesn't correctly retire the vpid in all circumstances.

One case is when machine A sends a message to machine B, aimed at a promise that is known to be decided on B. But before that message can arrive, some vat on B causes the promise to become resolved to an object back on A. We need B to reflect the message back to A in this case, but the comms vat only currently knows how to deliver inbound messages into the kernel.

Another case is when a B-decided promise is resolved on B, and then a message arrives from A that cites the promise in an argument. As the kernel has already forgotten about the promise ID, we must remind it about the contents. We can allocate a new vpid, or re-use the old one (which is easier, as we already have it in the remote table), but after using it the arguments of a send or resolve syscall, we must perform a resolve syscall on the vpid. (and then of course both vat and kernel will forget the value again, so we must do this each time the vpid is used, until the remote end gets the memo, aka the resolution message, and stops using that ID).

The branch I'm working on in #1404 will fix these cases as well. It's got tests for all the cases I could think of.

[warner]

This should be fixed by #1635