zlib: grow the output buffer of large async one-shot calls

[anonrig]

This builds on #66854, so only the last commit (753dd48) is new here.

After #66854 the async convenience methods hand the whole input to zlib in one write, but they still take one threadpool round trip per chunkSize (16 KiB by default) of output. A zlib.gunzip() that returns 4 MiB takes 257 round trips.

Only the concatenated result of these calls is visible to the caller, so this doubles the output buffer whenever it fills up, up to 1 MiB. 4 MiB of output now takes 10 round trips. The buffer never grows past what's needed to tell that maxOutputLength was exceeded, so it doesn't decompress any further past the limit than before. Results that fit in the first buffer take the same path as before, and the stream classes aren't touched. The extra memory while a call runs is the unused tail of the last buffer, so under 1 MiB.

Tests:

• test-zlib-convenience-async-large.js runs 2.25 MiB through every async method. It checks the result matches the sync methods byte for byte, and tries chunkSize of 64 and larger than the input. It also checks maxOutputLength one byte short, at 100000, at 1 and at the exact size. It passes on main and on zlib: finish async convenience calls in one write #66854 too.
• test-zlib-convenience-async-round-trip.js gets a 4 MiB case pinned at 10 round trips. It's 257 on zlib: finish async convenience calls in one write #66854.

Benchmarks

benchmark/compare.js, inflate.js method='inflate' with inputLen raised to get large outputs and n scaled down. My machine was heavily loaded (load average 70–100 from other builds), so the intervals are wide, but the effect is far outside them:

inputLen	vs #66854, run 1 (30 runs)	vs #66854, run 2 (40 runs)	vs main, run 1 / run 2
1 MiB	+332.45% ***	+379.94% ***	+359.03% *** / +349.12% ***
64 KiB	+40.25% ***	+47.88% ***

A/A (#66854 against itself, 1 MiB, 40 runs) is +2.97% ±20.84%.

The default 1 KiB configurations don't reach the new code, because their output fits in the first buffer. The --max-regression 5 gate over deflate.js, inflate.js, pipe.js and creation.js passed but came back inconclusive under that load (intervals around ±40%). Outside one-shot calls, the only change is an extra condition when a stream's output buffer fills up.

compare.js output

vs #66854, run 1
                                                          confidence   improvement   accuracy (*)    (**)   (***)
zlib/inflate.js n=2000 inputLen=1048576 method='inflate'  ***           +332.45 %   ±99.97%  ±134.26%  ±177.29%
zlib/inflate.js n=20000 inputLen=65536 method='inflate'   ***            +40.25 %   ±19.32%  ±25.78%  ±33.69%

vs main, run 1
zlib/inflate.js n=2000 inputLen=1048576 method='inflate'  ***           +359.03 %   ±100.05%  ±134.44%  ±177.65%

vs #66854, run 2
zlib/inflate.js n=2000 inputLen=1048576 method='inflate'  ***           +379.94 %   ±108.51%  ±145.17%  ±190.56%
zlib/inflate.js n=20000 inputLen=65536 method='inflate'   ***            +47.88 %   ±23.80%  ±31.60%  ±41.01%

vs main, run 2
zlib/inflate.js n=2000 inputLen=1048576 method='inflate'  ***           +349.12 %   ±64.07%  ±85.64%  ±112.25%

A/A, #66854 vs #66854
zlib/inflate.js n=2000 inputLen=1048576 method='inflate'                  +2.97 %   ±20.84%  ±27.65%  ±35.82%

Below, Chrome talks to three local servers, one each on main, #66854 and this PR, all with the same 4 MiB payload. It decodes a zlib.gzip() response and uploads a CompressionStream('gzip') body that the server decodes with zlib.gunzip(). The bytes match on all three. One zlib.gunzip() takes 258, 257 and 10 round trips. The per-call time is the median of five rounds, interleaved so the load hit each build alike.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.50%. Comparing base (2052d0d) to head (753dd48).
⚠️ Report is 13 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #66863      +/-   ##
==========================================
- Coverage   90.50%   90.50%   -0.01%     
==========================================
  Files         797      797              
  Lines      278195   278282      +87     
  Branches    53453    53472      +19     
==========================================
+ Hits       251777   251854      +77     
- Misses      16795    16806      +11     
+ Partials     9623     9622       -1     

Files with missing lines	Coverage Δ
lib/zlib.js	98.21% <100.00%> (+0.09%)	⬆️

... and 25 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mcollina]

The change is ok. Are the tests actually needed?