Run upgrade plan to completion during upgrade block

[mhofman]

What is the Problem Being Solved?

#8112 added support for running swingset work derived from the upgrade info contained in the governance proposal. However it did so by piggy backing on the the existing high priority queue, which means that action will likely not complete (or even start) before the end of the upgrade block.

Software upgrades are a great time to perform long expensive operations atomically instead of spreading them over multiple blocks like during normal execution. Any action triggered by an upgrade plan should run to completion during the upgrade block.

Description of the Design

Instead of pushing an action to the highPriorityQueue, we should instead:

• Push to an in memory only "run now" queue
  • Only if the block needs execution (hangover handling)
• In end block check if we have anything in this run now queue and if so
  • run any remaining swingset to quiescence
  • run the run now actions to quiescence (unlimited run policy)
  • empty the run now queue
  • run nothing else, not even a timer poll

Security Considerations

If the remaining swingset work, or the core proposal work does not get quiescent, the upgrade block may never finish. However that is a degenerate issue of #7938 and can be handled by the same mechanism

Scaling Considerations

If a "run now" action is performed outside of an upgrade block, it can interact negatively with cosmos consensus. While we do not have immediate plans to use this mechanism outside an upgrade block, it may be a good way to restart all vats before a software upgrade that will upgrade XS (see #7855)

Test Plan

Docker update test with a check that immediately after the upgrade block the core proposal is in effect (e.g. check a vat incarnation)

Upgrade Considerations

Yes