In OpenSSL, session resumption always happens in the default SSL context,
prior to invoking the SNI callback.  Further, unlike in TLSv1.2 and older
protocols, SSL_get_servername() returns values received in the resumption
handshake, which may be different from the value in the initial handshake.
Notably, this makes the restriction added in b720f650b insufficient for
sessions resumed with different SNI server name.

Considering the example from b720f650b, previously, a client was able to
request example.org by presenting a certificate for example.org, then to
resume and request example.com.

The fix is to reject handshakes resumed with a different server name, if
verification of client certificates is enabled in a corresponding server
configuration.

The build location of the resulting libatomic_ops.a was changed in v7.4.0
after converting libatomic_ops to use libtool.  The fix is to use library
from the install path, this allows building with both old and new versions.

Initially reported here:
https://mailman.nginx.org/pipermail/nginx/2018-April/056054.html

This is consistent with the rest of the code and fixes build on systems
with non-standard definition of struct iovec (Solaris, Illumos).

It now uses 5/4 times more memory for the pending buffer.

Further, a single allocation is now used, which takes additional 56 bytes
for deflate_allocs in 64-bit mode aligned to 16, to store sub-allocation
pointers, and the total allocation size now padded up to 128 bytes, which
takes theoretically 200 additional bytes in total.  This fits though into
"4 * (64 + sizeof(void*))" additional space for ZALLOC used in zlib-ng
2.1.x versions.  The comment was updated to reflect this.

While trying to close a stream in ngx_quic_close_streams() by calling its
read event handler, the next stream saved prior to that could be destroyed
recursively.  This caused a segfault while trying to access the next stream.

The way the next stream could be destroyed in HTTP/3 is the following.
A request stream read event handler ngx_http_request_handler() could
end up calling ngx_http_v3_send_cancel_stream() to report a cancelled
request stream in the decoder stream.  If sending stream cancellation
decoder instruction fails for any reason, and the decoder stream is the
next in order after the request stream, the issue is triggered.

The fix is to postpone calling read event handlers for all streams being
closed to avoid closing a released stream.

Previously, such packets were treated as long header packets with unknown
version 0, and a version negotiation packet was sent in response.  This
could be used to set up an infinite traffic reflect loop with another nginx
instance.

Now version negotiation packets are ignored.  As per RFC 9000, Section 6.1:

  An endpoint MUST NOT send a Version Negotiation packet in response to
  receiving a Version Negotiation packet.

When cropping stsc atom, it's assumed that chunk index is never 0.
Based on this assumption, start_chunk and end_chunk are calculated
by subtracting 1 from it.  If chunk index is zero, start_chunk or
end_chunk may underflow, which will later trigger
"start/end time is out mp4 stco chunks" error.  The change adds an
explicit check for zero chunk index to avoid underflow and report
a proper error.

Zero chunk index is explicitly banned in ISO/IEC 14496-12, 8.7.4
Sample To Chunk Box.  It's also implicitly banned in QuickTime File
Format specification.  Description of chunk offset table references
"Chunk 1" as the first table element.