"anachrophobia" replay error on restart

[warner]

We've noticed occasional errors when restarting a swingset (generally a cosmic-swingset ag-solo node) in which some vat is trying to replay the transcript but is making different syscalls than it did the previous time. @michaelfig and I came up with a hypothesis that the "command device" (which is listening for WebSocket connections) is becoming active too soon: an inbound connection is established (causing a message to be added to the run queue, for delivery to some handler vat) while it's in the middle of replaying the transcript. This causes a different set of messages to arrive at that vat than did in the previous run, which then triggers the anachrophobia error.

The fix will be to defer building the WebSocket listener until we've finished replaying the transcripts. I think that means waiting for the Promise that comes back from buildVatController() to fire. I know there's a kernel.start() that returns the Promise that fires after all transcripts have been replayed, but now I'm not sure whether that's exposed as a controller.start() or if it's folded into buildVatController().

We also need to change the way we react to this error: the entire kernel should be terminated. In the current code, an error is raised within the Vat Manager, but a higher caller is catching/logging/continuing because the same pathway might be triggered by ordinary vat code throwing an exception. The Vat Manager needs to set a flag that says "abandon ship" and not try to limp along anyways.

[michaelfig]

I've fixed the ordering of the kernel restart (replay happens before connections are initialised). Next comes making the abandonShip flag.