Refactor: Intorduce new JsValue.ExternalPusher interface to replace StreamSink.

[kentonv]

The design of StreamSink makes it fairly complicated and somewhat inefficient to implement. For example:

• It requires the use of setPipeline() so that the caller can start to enable promise pipelining on the StreamSink before it actually returns results.
• Every call must create a resultsStreamSink object in advance, before it knows if there will be any streams in the results.
• Generally there's just a lot of contortions involved in supporting it.

It occurred to me that a different design is possible: one where we have an object that is created per-IoContext (instead of per-call) which can be used to "push" values into that IoContext, so that they can then be referenced as externals by subsequent JsValues.

This PR implements this design, guarded behind an autogate. The autogate should not be enabled anywhere in production until all of production has received the code update -- this ensures that all of prod can understand the new protocol before anyone tries to use it.

Once the autogate is fully rolled out, we can delete StreamSink, which should be a pleasing reduction in complexity -- more so than the complexity that this PR adds.

#5744 shows what we'll be able to delete once this is landed. While the total quantity of code is neutral, I feel that StreamSink was a lot more complicated in the implementation details.

[kentonv]

This PR sets up for some other changes I need to make, including:

• Supporting channel tokens in process sandboxes.
• Supporting embedding remote promises into RPC payloads, and having them automatically replaced with their resolutions before delivery -- matching Cap'n Web's functionality.

[codspeed-hq]

CodSpeed Performance Report

Merging #5738 will degrade performance by 11.15%

_{Comparing kenton/rpc-external-pusher (513626f) with main (4a7a063)}

Summary

❌ 1 regression
✅ 56 untouched
⏩ 34 skipped¹

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

	Benchmark	BASE	HEAD	Efficiency
❌	Encode_ASCII_256[TextEncoder][0/0/256]	3.1 ms	3.5 ms	-11.15%

Footnotes

1. 34 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[kentonv]

Bolted awake at 6AM realizing: I broke e-order. Ugh.

[github-actions]

The generated output of @cloudflare/workers-types matches the snapshot in types/generated-snapshot 🎉

[kentonv]

OK I fixed e-order and actually simplified this quite a bit in the process.

It did require a hack in capnp: capnproto/capnproto#2475

But it works OK here.

[jasnell]

non-blocking nit:

Suggested change

	let promises = [];
	promises.push(stub.increment(1));
	promises.push(stub.increment(1));
	promises.push(stub.increment(1, abortSignal));
	promises.push(stub.increment(1));
	promises.push(stub.increment(1, readableStream));
	promises.push(stub.increment(1));
	let results = await Promise.all(promises);
	const results = await Promise.all([
	stub.increment(1),
	stub.increment(1),
	stub.increment(1, abortSignal),
	stub.increment(1),
	stub.increment(1, readableStream),
	stub.increment(1),
	]);

[kentonv]

I intentionally didn't write it that way since the order in which the increments are evaluated matters. While JavaScript probably guarantees that elements of an array literal are evaluated in left-to-right order (unlike C++), I didn't really want to write code that assumes anything about expression evaluation order.

[kentonv]

(rebased to resolve conflicts)

[kentonv]

Since wd-tests now have @all-autogate variants (#5760), I removed the variants of the tests that I added which manually enabled the external-pusher autogate.