async-flow: postpone wakeAll after first crank rather than first turn.

[erights]

At #9097 (comment) @mhofman writes

I just realized [a call to wakeAll] was commented out. I think it'll be a footgun if the flows are not awaken automatically.

because the wakeAll can only happen correctly after all prepares have been done. Thus, it should be postponed until after the first crank. But, as it currently reads:

  // Cannot call this until everything is prepared, so postpone to a later
  // turn. (Ideally, we'd postpone to a later crank because prepares are
  // allowed anytime in the first crank. But there's currently no pleasant
  // way to postpone to a later crank.)
  const allWokenP = E.when(null, () => adminAsyncFlow.wakeAll());

We now demonstrate this bug with the new async-flow-crank.test.js

[mhofman]

it should be postponed until after the first crank

I don't think it should be postponed until after the first crank. In particular we may in the future want to define a flow such that the vat upgrade fails if the replay of existing flows fails. That would require existing flows to be awoken in the first start crank.

the wakeAll can only happen correctly after all prepares have been done

There are 2 solutions to this:

• Keep the list of flows to wake up to be global, but trigger wakeAll after all flows have been redefined. That would require the flow tools to durably keep track of which flows had been defined, and only invoke wakeAll after the last one is redefined. Note you cannot use a simple counter because a new incarnation may define a new flow before a previous flow is redefined.
• implement async-flow: consider refactoring between per-flowTools operations and per-flow operations #9375 and instead wake the flows specific to each definition immediately after they are redefined.

[mhofman]

We recently realized that liveslots currently enforces that all kinds are reconnected by the time buildRootObject settles. For ZCF contracts, we're not providing a helper to wrap the start function providing asyncFlow. If the kinds defined by ZCF itself are defined before start is called, we could have this start wrapper call wakeAll after start's settlement, as we'd be relying on expected behavior that the contract reconnected all kinds.

[mhofman]

If we rely on the caller of prepareAsyncFlowTools to call adminAsyncFlow.wakeAll(), we likely should enforce or warn if it hasn't been called by the time an invocation is created or woken up.