Previously ngx_quic_compat_create_record() could try to encrypt a TLS
record even if encryption context was missing, which resulted in a NULL
pointer dereference.

The context is created by ngx_quic_compat_set_encryption_secret() called
from the OpenSSL keylog callback.  If an error occurred in that function,
the context could remain missing.  This could happen under memory pressure,
if an allocation failed inside this function.

The fix is to handle errors from ngx_quic_compat_set_encryption_secret()
and set qc->error to trigger an error after SSL_do_handshake() return.
Also, a check for context is added to ngx_quic_compat_create_record()
to avoid other similar issues.

Previously, it was possible to obtain a stateless reset token for a
connection by routing its packet to a wrong worker.  This allowed to
terminate the connection.

The fix is to bind stateless reset token to the worker number.

It uses a bloom filter to limit sending Stateless Reset packets no more
than once per second in average for the given address.  This allows to
address resource asymmetry from precomputed packets, as well as to limit
potential Stateless Reset exchange.

Now it accepts an optional salt, to be used in a subsequent change.

Made sure to send packets smaller than the triggering packet,
following RFC 9000, Section 10.3.3.

Reported-by: cyberspace61

Now to be valid, it also assumes the Connection ID we require from a client.

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