feat: add support for iterators

[metcoder95]

This is a first iteration of the support for (async)iterators on Piscina.

It is quite raw as I wanted to experiment first a bit how it can look like and also possibly draft the API of it; I'm still having some doubts about how can it look like and what differentiation can it have, so I just came with a easy one of, returning an Stream every time an iterator is identified while handling the worker's workload.

Further optimizations:

• Replace port.postMessage with a ring buffer to reduce overhead - for further PRs
• Properly implement WorkerStream which will be an abstraction of the ring buffer implementation - same as previous point
• Shape API
• Docs

[metcoder95]

It should be ready for review; I'm quite curious about seeing an ergonomic enough API. I already have some baseline for optimizations, especially around messages between worker and main thread, but I'd like to start gathering feedback about the API shape and leave the further enhancements for upcoming PRs

[metcoder95]

I'll be adding docs later this week

[jdmarshall]

Reading the code, I’m unclear how or if you are managing back pressure on the worker. It looks like you’re not waiting for the parent process to call next(), which would be fairly poor performance, something you could emulate entirely with postMessage(). What keeps the receiver from getting backed up reading messages?

[metcoder95]

Reading the code, I’m unclear how or if you are managing back pressure on the worker. It looks like you’re not waiting for the parent process to call next(), which would be fairly poor performance, something you could emulate entirely with postMessage(). What keeps the receiver from getting backed up reading messages?

Currently, how to implement backpressure was not really clear with the current setup.
For this PoC, the Worker is the one that drives the flow of the data; until the worker calls postMessage with done = true, the main thread will be sit waiting for the upcoming chunk.

Tho, the other way around is kind of more complicated (what if the main thread wants to pause the stream or the stream's buffer is full and needs drain).

I shift my focus to #746 using ring-buffers; I'll try to cover more of this on those efforts

[jdmarshall]

So the buffer length will end up dictating the max queuing before the sender stalls. Sounds fair.