local (non-consensus) scheduling of XS snapshots

[warner]

What is the Problem Being Solved?

As described in #3428 , writing an XS snapshot necessarily (and appropriately) causes a GC sweep, which is visible to the consensus state because it affects the timing of "organic" (non-forced) GC sweeps, which provokes GC syscalls, which provoke GC action deliveries, which might provoke comms messages.

We'd prefer to allow each validator to be able to independently choose when to write snapshots.

TODO: copy more text from #3428 with the options available to us.

Description of the Design

Security Considerations

Test Plan

[FUDCo]

In principle it strikes me that the GC associated with a snapshot is no different from an organic GC in that it can happen at arbitrary times. The issue really is the release of visible GC-driven events (drop, retire, et al) into the consensus stream. If XS' GC is indeed complete, then we can at any arbitrary time, i.e., at a time and place of our choosing, assure ourselves that we know all the garbage there is to be collected (i.e., that all of the potentially visible GC-driven events that could be known up to that point are known). So this reduces the problem to "when do we release GC actions into the consensus stream?", which seems like a question we can provide a deterministic answer for.

[aj-agoric]

Per discussion with @mhofman closing as will not do as we have changed course.

[mhofman]

To clarify, we have since decided to make snapshots an integral part of consensus data. While we could imagine allowing extra snapshots performed outside of consensus, it would require that we fix all liveslots sensitivity to gc (#6784), including on non-organic gc which treat WeakRef as strong to hide the effect from liveslots (the gc triggered by snapshots is considered non-organic by XS)