zlib: add zstd support

[jkrems]

Adds ZstdCompress and ZsdDecompress to the zlib module which can be used to compress/decompress with the Zstandard ("zstd") algorithm.

Notable omissions:

• Providing dictionaries isn't implemented.
• The docs in zlib.md don't call out any params beyond the basic compression level.

The code follows similar patterns to the PR that added Brotli support. Just that instead of brotli, it adds the equivalent zstd APIs. Just like Brotli, this required separate compression/decompression context objects.

Zstd itself has been around and stable for multiple years but this PR is early in terms of web support: It only just starts shipping by default in Chrome 123. On the other hand, by shipping in Chrome it will soon be supported quite widely on the web. Firefox also signaled support (https://bugzilla.mozilla.org/show_bug.cgi?id=1301878#c65). Zstd is now enabled on the web and supported by both Chrome and Firefox: https://caniuse.com/zstd

Official support in node.js would allow passing additional WPTs around fetch (nodejs/undici#2847).

[nodejs-github-bot]

Review requested:

• @nodejs/security-wg

[jkrems]

Alright, got up to making the basics (seemingly) work:

$ out/Debug/node -p 'zlib.zstdDecompressSync(zlib.zstdCompressSync("Hello World")).toString()'
Hello World

[KhafraDev]

cc @nodejs/zlib @nodejs/security-wg

[jkrems]

Rebased & updated zstd to the latest release (1.5.5 --> 1.5.6).

[anonrig]

Why cctx?

Suggested change

	cctx_.reset(ZSTD_createCCtx());
	ctx.reset(ZSTD_createCCtx());

[jkrems]

The c is for compression (cctx vs dctx). Given that we only ever deal with one or the other, we could drop that marker from the fields. But it seems worthwhile to match the naming used by zstd itself.

[anonrig]

Can you also update license_builder?

[jkrems]

Can you also update license_builder?

The changes to the top-level LICENSE file were generated by running ./tools/license-builder.sh. It's at the very end of the file changes in the Github UI.

[jkrems]

Moved the init errors into C++ where we can add more context to them.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 87.89%. Comparing base (22ea302) to head (e9e1f0b).
Report is 2 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff            @@
##             main   #52100    +/-   ##
========================================
  Coverage   87.89%   87.89%            
========================================
  Files         651      651            
  Lines      183364   183680   +316     
  Branches    35714    35756    +42     
========================================
+ Hits       161171   161453   +282     
- Misses      15465    15494    +29     
- Partials     6728     6733     +5     

Files with missing lines	Coverage Δ
lib/internal/errors.js	94.92% <ø> (+<0.01%)	⬆️
lib/zlib.js	97.98% <ø> (-0.21%)	⬇️
src/node_errors.h	84.21% <ø> (ø)
src/node_metadata.cc	91.80% <ø> (+0.13%)	⬆️
src/node_zlib.cc	78.74% <ø> (+0.25%)	⬆️

... and 29 files with indirect coverage changes

[maxpain]

Hello. Any ETA for this?

[jasnell]

@jkrems ... can you give this a rebase?

[jkrems]

@jasnell I can but at this point I have spend quite bit of time on this PR without a clear signal on whether this would be likely to land (in this form or another). So it would be easier to justify if there was a tentative "yep, the high level approach looks good". By high level I mean something like "roughly following brotli integration in terms of API, using the facebook zstandard native implementation as the backing".