Mechanism to handle infinite message loops

[mhofman]

What is the Problem Being Solved?

Through metering we have a way to prevent a run-away cranks (either synchronous or locally resolved promises). However we don't have any way to prevent a run-away message loop between 2 or more vats.

Currently the chain scheduler implemented by cosmic-swingset has run to completion semantics, and will not process any external input until the current work finishes, allowing a swingset run-away.

Description of the Design

A Swingset controller method that causes all sends currently on the run-queue to be rejected.
It's unclear what to do with pending promise notifications, but likely these could be transformed into rejections as well.

Security Considerations

These rejections are not guaranteed to cause the execution to ultimately complete, the code could handle (ignore) the rejections and continue it message loop.

There is also a risk that such a rejection would cause a vat to fail, and if it's a critical vat, interrupting swingset at that crank may be too late and it would have been preferable to interrupt swingset instead of rejecting all pending run queue events.

Scaling Considerations

We should consider whether this mechanism should be reserved to manual interventions, likely only usable during a chain upgrade, or whether to automatically trigger it once a swingset run has consumed a certain amount of computrons (with a limit likely higher than a block's worth of computrons, possibly with some action types like core eval exempt).

Test Plan

TBD

[mhofman]

Closing in favor of #7938