Add warning for promises not settled promptly

[mhofman]

What is the Problem Being Solved?

Liveslots does not currently have any mechanism to resolve a promise across incarnations: the resolvers for a promise decided by a vat cannot be durably stored or recovered after an upgrade. Given that limitation, the kernel automatically rejects any promise decided by a vat on its behalf during an upgrade (#6694).

We currently define a vat to be resumable if it can be restarted / upgraded when Swingset is quiescent (it's run-queue is empty) without disrupt existing executions (its own or vats it interacted with).

Taken together that means a vat is not resumable if it remains the decider for unsettled promises by the time swingset becomes quiescent (aka the promise was not resolved promptly and requires external input to settle), and the subscriber to this promise does not have a mechanism to obtain a new equivalent promise. Such mechanisms exist in user-land in the form of:

• A subscriber to a notifier will usually watch and react to a getUpdateSince() result promise being rejected with a disconnection reason
• A vow watcher uses watches the result promise of the vow's shorten() and automatically re-attempts shortening when encountering a disconnection reason
• Vow tools provide a retryable helper which automatically re-executes a provided async function when encountering a disconnection reason as result.

While all these mechanisms should use watchPromise to guard against the subscribing side's own upgrade potential, this is an independent problem possibly solved (partially) by #9771. Any promise not resolved promptly and not using these known patterns can be assumed to represent a resumability hazard and be warned about.

Description of the Design

The swingset kernel would keep track of any new promise, and info about its "source" (usually the message send that created it, or the vat and delivery info during which it was first exported otherwise). Whenever a tracked promise settles, the kernel would forget about its tracking info. When the kernel run-queue becomes empty, the kernel would emit a console warning diagnostic for each of the tracked promise, likely excluding any promise from known resumable mechanisms, before emptying the list of tracked promises.

Security Considerations

None. This only provides diagnostics to the external observer of swingset.

Scaling Considerations

This requires storing in committed state this tracking information because a run to quiescence may be split by the host over multiple commit points (in the case of cosmic-swingset, multiple blocks). Swingset already stores information about all pending promises, and the information is transient, so this does not constitute a significant increase in storage or compute costs.

Test Plan

TBD. We may want a mode where a swingset run fails if there are any unexpected unsettled promises on quiescence.

Upgrade Considerations

This functionality requires changes to the swingset kernel, which would be deployed as part of a chain software upgrade. The requirement for storage across block boundaries makes this a consensus affecting change to the software. No special upgrade migration is necessary as long as a missing list info is equivalent to an empty list.