test: fix test-worker-memory.js for large cpu #s

[mhdawson]

This test consistently failed on a system with a
large number of cores (~120). Cap the number of
concurrent workers so we'll stay consistently within
the "slack" allowed with respect to rss.

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• commit message follows commit guidelines

[nodejs-github-bot]

Lite-CI: https://ci.nodejs.org/job/node-test-pull-request-lite-pipeline/3170

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/22202/

[gireeshpunathil]

As a side note: I had come across the same issue and attempted to address it in a similar manner, but did not proceed when I realized that there is another problem, that may be harder to solve: when too many workers run in truly parallel manner, the rss growth pattern is observed to be non-uniform and non-deterministic (not a function of the worker count, but the degree of parallelism - order in which threads were accessing the memory, scheduling, the time gap between worker exeution and the rss data collection etc.

This fix looks reasonable; but if the issue recurs even with this, we should suspect the non-deterministic behavior of rss and may be we should fix the number of workers to a lowest possible number of CPUs in our CI.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/22217/

[mhdawson]

CI was good landing.

[mhdawson]

See that comment was changed sinc last CI run. Lite CI to be safe: https://ci.nodejs.org/job/node-test-pull-request-lite-pipeline/3198/

[mhdawson]

Landed as f96a660