stream: allow infinite concurrency

[rluvaton]

adding this so we can use it in:

• test-runner: run tests as soon as find them #48584 (comment)

which is needed as we don't want to wait for the prev tests to finish before starting a new one (same issue as in #46132)

This has a pitfall in using concurrency: Infinity on infinite stream

[nodejs-github-bot]

Review requested:

• @nodejs/streams

[rluvaton]

the macOS failed test is unrelated:
test-inspector-debug-end.js

[MoLow]

I am not sure this asserts concurrency works

[rluvaton]

The test meant to make sure that concurrency: Infinity does not throw an error, but you are right, it does not test that concurrency works, fixed it

[benjamingr]

Why do we need a timer here? Can't this just be something like:

let count = 0; // or t.mock
Readable.from(Array(1000).fill()).map(() => {
  count++;
  return new Promise(() => {});
}, { concurrency: Infinity }).toArray().catch(common.mustNotCall());

await setImmediate(); // from timers/promises
strictEqual(count, 1000);

[benjamingr]

@ronag I'm not sure about this wdyt?

[mcollina]

I don't see any good reason to allow this API: it's a gateway to memory leaks.

[ljharb]

How is it different than allowing Number.MAX_SAFE_INTEGER?

[rluvaton]

I don't see any good reason to allow this API: it's a gateway to memory leaks.

@mcollina we can log a warning in case the array reaches some size like what's happening when having a lot of listeners to event emitter

[MoLow]

we can log a warning in case the array reaches some size like what's happening when having a lot of listeners to event emitter

then why add this option in the first place?