Sticky sessions allow to route the same client to the same upstream server.

- upstream structures are extended to keep session-related information

- existing balancing modules are updated to provide an id of the selected
  server (SID) in pc->sid, and to select the server, given it's SID.

- other balancing modules are allowed to set the pc->hint value to choose
  the desired peer.  The sticky module will not change the hint if it's
  already set.

- the feature is enabled by default and can be disabled with the
  "--without-http_upstream_sticky" switch of the configure script.

The following configuration can be used to enable sticky sessions for
supported balancing modules:

    upstream u1 {
        server 127.0.0.1:8080;
        server 127.0.0.1:8081;

        sticky cookie server_id expires=1h domain=.example.com path=/;
    }

Co-authored-by: Ruslan Ermilov <ru@nginx.com>
Co-authored-by: Roman Arutyunyan <arut@nginx.com>
Co-authored-by: Maxim Dounin <mdounin@mdounin.ru>

The module allows to use HTTP/2 protocol for proxying.
HTTP/2 proxying is enabled by specifying "proxy_http_version 2".

Example:

    server {
        listen 8000;

        location / {
            proxy_http_version 2;
            proxy_pass https://127.0.0.1:8443;
        }
    }

    server {
        listen 8443 ssl;
        http2 on;

        ssl_certificate certs/example.com.crt;
        ssl_certificate_key certs/example.com.key;

        location / {
            return 200 foo;
        }
    }

For certain compilers we embed the compiler version used to build nginx
in the binary, retrievable via 'nginx -V', e.g.

  $ ./objs/nginx -V
  ...
  built by gcc 15.2.1 20250808 (Red Hat 15.2.1-1) (GCC)
  ...

However if the CFLAGS environment variable is set this would be omitted.

This is due to the compiler specific auto/cc files not being run when
the CFLAGS environment variable is set, this is so entities can set
their own compiler flags, and thus the NGX_COMPILER variable isn't set.

Nonetheless it is a useful thing to have so re-work the auto scripts to
move the version gathering out of the individual auto/cc/$NGX_CC_NAME
files and merge them into auto/cc/name.

Link: <https://github.com/nginx/nginx/issues/878>

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 support first appeared in OS X Mavericks 10.9 and documented since
OS X Yosemite 10.10.

It has a subtle implementation difference from other operating systems
in that the TCP_KEEPALIVE socket option (used in place of TCP_KEEPIDLE)
isn't inherited from a listening socket to an accepted socket.

An apparent reason for this behaviour is that it might be preserved for
the sake of backward compatibility.  The TCP_KEEPALIVE socket option is
not inherited since appearance in OS X Panther 10.3, which long predates
two other TCP_KEEPINTVL and TCP_KEEPCNT socket options.

Thanks to Andy Pan for initial work.

Similarly to the QUIC API originated in BoringSSL, this API allows
to register custom TLS callbacks for an external QUIC implementation.
See the SSL_set_quic_tls_cbs manual page for details.

Due to a different approach used in OpenSSL 3.5, handling of CRYPTO
frames was streamlined to always write an incoming CRYPTO buffer to
the crypto context.  Using SSL_provide_quic_data(), this results in
transient allocation of chain links and buffers for CRYPTO frames
received in order.  Testing didn't reveal performance degradation of
QUIC handshakes, https://github.com/nginx/nginx/pull/646 provides
specific results.

All definitions now set in ngx_event_quic.h, this includes moving
NGX_QUIC_OPENSSL_COMPAT from autotests to compile time.  Further,
to improve code readability, a new NGX_QUIC_QUICTLS_API macro is
used for QuicTLS that provides old BoringSSL QUIC API.

This extends the target selection implemented in dad6ec3aa63f to support
Windows ARM64 platforms.  OpenSSL support for VC-WIN64-ARM target first
appeared in 1.1.1 and is present in all currently supported (3.x)
branches.

As a side effect, ARM64 Windows builds will get 16-byte alignment along
with the rest of non-x86 platforms.  This is safe, as malloc on 64-bit
Windows guarantees the fundamental alignment of allocations, 16 bytes.