In RunUtils test support deterministic boot snapshots

[turadg]

What is the Problem Being Solved?

Tests in the boot package currently boot a full SwingSet kernel for each test case in order to reach a usable starting state. Boot is deterministic but expensive. As a result:

• Test runtime is dominated by repeated kernel initialization.
• Tests that only exercise post-boot behavior still pay full boot cost.
• Developers are discouraged from writing fine-grained tests because each test requires recreating the entire system state.

Because boot is expensive and global kernel state is not easily isolated, we often resort to running tests serially. This reduces parallelism and contributes to the broader test performance and targetability issues discussed in #8613.

We would like a way to boot once, capture a deterministic kernel state snapshot, and restore from that snapshot for subsequent tests.

In other words, treat boot as a checkpoint in a deterministic state machine and allow tests to fork from that checkpoint. This would enable isolated tests without requiring repeated full boot, and would allow safe parallelization.

Description of the Design

Extend RunUtils (or adjacent test harness utilities) to support:

1. Creating a boot snapshot:

   • Initialize SwingSet.
   • Run to quiescence.
   • Extract a serialized representation of the kernel storage state.

2. Restoring from a snapshot:

   • Create a fresh in-memory storage instance.
   • Load the serialized snapshot into it.
   • Construct a new controller bound to that storage.

Proposed high-level API shape:

const snapshot = await makeBootSnapshot(config);

const controller = await makeControllerFromSnapshot(snapshot);

OR

bootOnce produces a boot context, and each test calls fork on that context to obtain an isolated controller instance.

Constraints:

• Boot must be deterministic.
• Snapshot must fully capture kernel state, including monotonic counters.
• Restores must not share mutable state between tests.
• No reliance on process-level state outside the kernel store.

This would likely operate at the kernel storage layer (KV store dump/restore), not at the vat heap snapshot level.

Security Considerations

• Snapshots must not introduce capability leaks across tests.
• Restored controllers must not share object identity or authority with other restored instances.
• Any serialization format must preserve integrity of kernel invariants.

Scaling Considerations

• Improves test performance and developer iteration speed.
• Enables running many isolated tests against the same deterministic boot baseline.
• Removes the need for serial-only execution patterns.
• Supports fork-based testing and potential fuzzing patterns in the future.

Test Plan

• Add tests that:
  • Boot once and snapshot.
  • Restore twice.
  • Execute divergent operations in each restored instance.
  • Confirm no cross-contamination.
• Confirm object ID counters and promise ID allocation remain correct after restore.
• Compare behavior of:
  • Full fresh boot
  • Snapshot restore
    to ensure equivalence.

Upgrade Considerations

• Snapshot format should be versioned or explicitly scoped to test-only usage.
• Changes to kernel storage schema may invalidate prior snapshots.
• This feature is intended for test infrastructure, not production chain snapshots.