Depth first processing of inbound actions

[mhofman]

What is the Problem Being Solved?

Currently all inbound actions in a block are delivered in one chunk into SwingSet devices, which results in items added to the SwingSet runqueue. Since the SwingSet runqueue is singular and FIFO, external deliveries contend with each other since every message to other vat goes to the back of the runqueue.

Description of the Design

While we plan on better handling this future scheduling work (multiple swingset queues, LIFO-ish queue or "flow" based processing, etc.), one simple solution for the PSM use case (no internal fan out) is to simply pluck cosmos actions one by one, and run SwingSet to "completion" before moving on to the next action.

Since the existing action queue is designed to be flushed by the end of the block, this requires a new queue of actions stored in cosmic-swingset JS side, stored in the swingStore host section. It also requires some changes to the run policy logic to allow multiple runs of the SwingSet controller.

Security Considerations

One risk of run-to-completion or LIFO queueing is that an infinite message loop would starve subsequent actions / messages. While the current contract code is trusted and will not trigger such loops, we can be somewhat defensive against this and allow new actions to be queued if the run queue is below a certain threshold. That means the action processing would not be strictly FIFO, which we don't actually care about. However this may not be a sufficient mitigation if one could trigger multiple message loops.

We also need to be careful regarding hangover inconsistency, and make sure that whatever data we use to make decision on whether to wait to deliver a new action into swingset or not is persisted appropriately.

Test Plan

Yes

[mhofman]

This is a somewhat simpified version of #5966

[mhofman]

Preliminary refactor for this work landed in #6193.