zlib-ng-compat 2.2.2 (new formula)

[cho-m]

• Have you followed the guidelines for contributing?
• Have you ensured that your commits follow the commit style guide?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

---

Potential formula for providing zlib-ng with the zlib compatible API. Current zlib-ng formula is built with separate API for non-conflicting installation.

In future, could follow Fedora and use this as default zlib (https://fedoraproject.org/wiki/Changes/ZlibNGTransition) to provide a more optimized alternative for Linux users.

Though transition may want to wait for some other distros to adopt (Arch Linux recently introduced https://archlinux.org/packages/extra/x86_64/zlib-ng-compat/ so they could go this route).

May also be possible for Linux users to inject this via one of the supported ld.so environment variables as mentioned in https://github.com/zlib-ng/zlib-ng?tab=readme-ov-file#install

For Linux distros, an alternative way to use zlib-ng (if compiled in zlib-compat mode) instead of zlib, is through the use of the LD_PRELOAD environment variable. If the program is dynamically linked with zlib, then the program will temporarily attempt to use zlib-ng instead, without risking system-wide instability.

Less useful on macOS as we typically use system zlib, though we could consider it for MySQL which forces us to use a newer version of zlib.

[bayandin]

Should we add it to synced_versions_formulae.json (with zlib-ng)?