In rare cases, it was possible to get into this error state on reload
with improperly updated file timestamps for certificate and key pairs.

The fix is to retry on X509_R_KEY_VALUES_MISMATCH, similar to 5d5d9adcc.
Additionally, loading SSL certificate is updated to avoid certificates
discarded on retry to appear in ssl->certs and in extra chain.

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.

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>

Previously, it was not possible to send acknowledgments if the
congestion window was limited or temporarily exceeded, such as
after sending a large response or MTU probe.  If ACKs were not
received from the peer for some reason to update the in-flight
bytes counter below the congestion window, this might result in
a stalled connection.

The fix is to send ACKs regardless of congestion control.  This
meets RFC 9002, Section 7:
: Similar to TCP, packets containing only ACK frames do not count
: toward bytes in flight and are not congestion controlled.

This is a simplified implementation to send ACK frames from the
head of the queue.  This was made possible after 6f5f17358.

Reported in trac ticket #2621 and subsequently by Vladimir Homutov:
https://mailman.nginx.org/pipermail/nginx-devel/2025-April/ZKBAWRJVQXSZ2ISG3YJAF3EWMDRDHCMO.html