Replace JsInstance pool with single worker and FIFO queue

[joshua-spacetime]

Description of Changes

Before this change, JS reducer requests borrowed a JsInstance from a pool. If no idle instance was available, we created another instance, which meant another V8 worker thread. Under load, this meant reducers bouncing across multiple OS threads.

After this change, JS reducers go through a single long-lived JsInstance fed by a FIFO queue which results in much better cache locality. More accurately, each module now allocates a single OS thread, on which reducers (and most operations) run. Modules do not share workers/threads. And modules do not create multiple threads for running reducers.

Note, the original instance pool is still used for procedures. It should probably be bounded, but I didn't make any changes to it. It's also used for executing views during initial subscription to avoid a reentrancy deadlock. The latter should be fixed and moved over to the JS worker thread at some point.

API and ABI breaking changes

N/A

Expected complexity level and risk

4

Testing

NODE_OPTIONS="--max-old-space-size=8192" \
MAX_INFLIGHT_PER_WORKER=512 \
BENCH_PRECOMPUTED_TRANSFER_PAIRS=1000000 \
pnpm bench test-1 --seconds 10 --concurrency 50 --alpha 1.5 --connectors spacetimedb

50K TPS -> 85K TPS on m2 mac

[Centril]

On phoenix nap + rust client, this takes performance to about 150k TPS, which is around 15k lower than for the rust module.

[coolreader18]

LGTM now