TrapCaps for async host, synchronous guest relationships

[michaelfig]

Fixes #2846 while we're in the neighbourhood.

As discussed with @erights and @kriskowal, this implements the possibility for a Host captp endpoint to serve synchronous Trap requests made by a trusting Guest captp endpoint. See test-trap.js for how it works.

Essentially, Alice's can set opts.giveTrapReply and serve a makeTrapHandler(name, object), which when given the right opts.takeTrapReply on Bob's side, permits Bob to call Trap(remotable)[prop](...args) (or Trap.get(remotable)[prop] or Trap(remotable)(...args)), blocking and waiting for Alice to asynchronously resolve the answer normally, but Bob sees the result as if it were synchronous.

This must only be used when Bob can and must depend on Alice's correct functioning, such as when Alice is a device-driver-like service. Using it in other ways leads to madness.

[kriskowal]

I’ve left some comments. I definitely need to read what’s already in CapTP top-to-bottom to have the knowledge necessary to give this a hearty stamp. What I see looks fine, except a strong feeling handler behaviors shouldn’t be conflated into a single utility function.

I would like to see a code sample of how this would interact with SharedBuffer and Atomics, if not a working example.

[michaelfig]

I would like to see a code sample of how this would interact with SharedBuffer and Atomics, if not a working example.

I may supply such an example, but it will be only a part of a PR stacked on top of this PR. The simplest correct implementation of Worker/postMessage/SharedArrayBuffer/Atomics is at least 100 lines of code, even when given the foundation in this PR.

[michaelfig]

I would like to see a code sample of how this would interact with SharedBuffer and Atomics, if not a working example.

@erights please hold off on this review until I provide an example as requested by @kriskowal. The factoring of such an example will inform what API captp should provide.

[michaelfig]

@erights and @kriskowal, this is now fully-baked and ready for a review. Notably, the test-sync.js tests demonstrate the use of Workers communicating via SharedArrayBuffer with Atomics.

[erights]

Just some review comments so far.

[erights]

If I remain tardy in reviewing this PR (sorry), would it be useful to extract the #2846 fix as a distinct PR so it can go in asap?

[erights]

Comments so far.

[erights]

The loopback case doesn't make any use of iteration, because of course not. This has me wondering whether the generic types should hide rather that expose the iterators on both side, so that it is only the business of an individual makeGuest/makeHost pair (like atomics) whether it needs iterators or not.

[erights]

#3171 (comment) is my only comment that is likely a bug. The others are questions, suggestions, or things to discuss.

[erights]

LGTM!

But please don't merge until we talk