Async-flow aware zone

[mhofman]

What is the Problem Being Solved?

To support async flow exo methods (#9832) without liveslots support (#9881), we need to provide exo state access on top of the existing exo infrastructure. This could be done as an async-flow aware zone which imposes some restrictions on exo definitions (no single facet exo, and possibly no singleton exo either), and expose the async flow maker on the zone itself, as well as supports guard "marks" to designate exo methods as being async flow enabled.

Description of the Design

An async-flow zone which does the following:

• An M.asyncFlow guard which indicates the corresponding behavior methods should be used as an async-flow definition.
• Wraps exo definitions to:
  • recognize these guard markers and add an internal state accessor facet for exo kits, or fail definition if used on single facet definitions
  • Disallow definition of facet names reserved for internal use
• Allow definition of async-flow functions directly on through the zone
  • Consider overloading the future support of definition of exo functions (see #10435): A singleton exo whose behavior is a function, and in this case where the guard must have the async flow mark)

For compatibility with endowments, it would be great if the makers of these exos could be durable compatible, but that requires changes in the Virtual Object Manager to support in the first place.

Security Considerations

None, zones are already a user land wrapper on top VatData. This is simply further expanding the capabilities of that wrapper.

Scaling Considerations

To avoid rewriting the context object for every method call, it's preferable to prevent async flow methods on single facet exos, and disallow internal facet names from all multi facet exos (likely _ prefixed)

Test Plan

Fake liveslots based tests are likely sufficient

Upgrade Considerations

User land library update that can be published to NPM.

In case we ever implement support in liveslots for the state accessor facet (#9881), we may want newer definitions through this async-flow aware zone to use that mechanism, however for existing definitions we may need to maintain the behavior described above. This points towards a versioning of exo definitions, which is a similar problem to verifying baggage compatibility of exo definitions (see #10434)

[mhofman]

Related, we will likely want to make M.await be vow aware too (issue TBD), and figure out how M.callWhen and M.asyncFlow interact. (M.callWhen(M.asyncFlow(M.await(Foo))) ?)