The ssl_certificate_compression directive allows to send compressed
server certificates.  In OpenSSL, they are pre-compressed on startup.
To simplify configuration, the SSL_OP_NO_TX_CERTIFICATE_COMPRESSION
option is automatically cleared if certificates were pre-compressed.

SSL_CTX_compress_certs() may return an error in legitimate cases,
e.g., when none of compression algorithms is available or if the
resulting compressed size is larger than the original one, thus it
is silently ignored.

Certificate compression is supported in Chrome with brotli only,
in Safari with zlib only, and in Firefox with all listed algorithms.
It is supported since Ubuntu 24.10, which has OpenSSL with enabled
zlib and zstd support.

The actual list of algorithms supported in OpenSSL depends on how
the library was configured; it can be brotli, zlib, zstd as listed
in RFC 8879.

Certificate compression is supported since OpenSSL 3.2, it is enabled
automatically as negotiated in a TLSv1.3 handshake.

Using certificate compression and decompression in runtime may be
suboptimal in terms of CPU and memory consumption in certain typical
scenarios, hence it is disabled by default on both server and client
sides.  It can be enabled with ssl_conf_command and similar directives
in upstream as appropriate, for example:

    ssl_conf_command Options RxCertificateCompression;
    ssl_conf_command Options TxCertificateCompression;

Compressing server certificates requires additional support, this is
addressed separately.

The kevent udata field was changed from intptr_t to "void *",
similar to other BSDs and Darwin.

The NGX_KQUEUE_UDATA_T macro is adjusted to reflect that change,
fixing -Werror=int-conversion errors.

The NGX_KQUEUE_UDATA_T macro is used to compensate the incompatible
kqueue() API in NetBSD, it doesn't really belong to feature tests.

The change limits the macro visibility to the kqueue event module.
Moving from autotests also simplifies testing a particular NetBSD
version as seen in a subsequent change.

The kevent udata field is special in that we maintain compatibility
with NetBSD versions that predate using the "void *" type.

The fix is to cast to intermediate uintptr_t that is casted back to
"void *" where appropriate.

Prior to OpenSSL 3.0, OPENSSL_VERSION_NUMBER used the following format:

MNNFFPPS: major minor fix patch status

Where the status nibble (S) has 0+ for development and f for release.

The format was changed in OpenSSL 3.0.0, where it is always zero:

MNN00PP0: major minor patch

No functional changes.

A bug with the "quic_transport_parameters" extension and SNI described
in cedb855d7 is now fixed in the OpenSSL 3.5.1 release, as requested
in https://github.com/openssl/openssl/pull/27706.

In OpenSSL 3.5.0, the "quic_transport_parameters" extension set
internally by the QUIC API is cleared on the SSL context switch,
which disables sending QUIC transport parameters if switching to
a different server block on SNI.  See the initial report in [1].

This is fixed post OpenSSL 3.5.0 [2].  The fix is anticipated in
OpenSSL 3.5.1, which has not been released yet.  When building
with OpenSSL 3.5, OpenSSL compat layer is now used by default.
The OpenSSL 3.5 QUIC API support can be switched back using
--with-cc-opt='-DNGX_QUIC_OPENSSL_API=1'.

[1] https://github.com/nginx/nginx/issues/711
[2] https://github.com/openssl/openssl/commit/45bd3c3798

There were a few random places where 0 was being used as a null pointer
constant.

We have a NULL macro for this very purpose, use it.

There is also some interest in actually deprecating the use of 0 as a
null pointer constant in C.

This was found with -Wzero-as-null-pointer-constant which was enabled
for C in GCC 15 (not enabled with Wall or Wextra... yet).

Link: <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117059>