HTTP CONNECT method is now supported in HTTP/1 connections.  It's disabled
in all currently existing standard modules.  A new variable $port is added
that contains the port passed by client in HTTP CONNECT.  The $host
variable contains the host part.

A new module ngx_http_tunnel module is added which establishes a tunnel
to a backend.  It supports the newly added HTTP CONNECT method and can be
used to set up an HTTP CONNECT proxy.

As recommended by RFC 9110, proxy target should be restricted to ensure
safe proxying:

: Proxies that support CONNECT SHOULD restrict its use to a limited set
: of known ports or a configurable list of safe request targets.

Example config:

    server {
        listen 8000;

        resolver dns.example.com;

        map $port $tun_port {
            80             1;
            443            1;
        }

        map $host $tun_host {
            hostnames;

            example.com    1;
            *.example.org  1;
        }

        map $tun_port$tun_host $tun {
            11             $host:$port;
        }

        location / {
            tunnel_pass $tun;
        }
    }

Request:

    $ curl -px 127.0.0.1:8000 http://example.com

After fixing ngx_http_v3_encode_varlen_int() in 400eb1b628,
NGX_HTTP_V3_VARLEN_INT_LEN retained the old value of 4, which is
insufficient for the values over 1073741823 (1G - 1).

The NGX_HTTP_V3_VARLEN_INT_LEN macro is used in ngx_http_v3_uni.c to
format stream and frame types.  Old buffer size is enough for formatting
this data.  Also, the macro is used in ngx_http_v3_filter_module.c to
format output chunks and trailers.  Considering output_buffers and
proxy_buffer_size are below 1G in all realistic scenarios, the old buffer
size is enough here as well.

Previously, the expiration caused QUIC connection finalization even if
there are application-terminated streams finishing sending data.  Such
finalization terminated these streams.

An easy way to trigger this is to request a large file from HTTP/3 over
a small MTU.  In this case keepalive timeout expiration may abruptly
terminate the request stream.

Passwords were not preserved in optimized SSL contexts, the bug had
appeared in d791b4aab (1.23.1), as in the following configuration:

    server {
        proxy_ssl_password_file password;
        proxy_ssl_certificate $ssl_server_name.crt;
        proxy_ssl_certificate_key $ssl_server_name.key;

        location /original/ {
            proxy_pass https://u1/;
        }

        location /optimized/ {
            proxy_pass https://u2/;
        }
    }

The fix is to always preserve passwords, by copying to the configuration
pool, if dynamic certificates are used.  This is done as part of merging
"ssl_passwords" configuration.

To minimize the number of copies, a preserved version is then used for
inheritance.  A notable exception is inheritance of preserved empty
passwords to the context with statically configured certificates:

    server {
        proxy_ssl_certificate $ssl_server_name.crt;
        proxy_ssl_certificate_key $ssl_server_name.key;

        location / {
            proxy_pass ...;

            proxy_ssl_certificate example.com.crt;
            proxy_ssl_certificate_key example.com.key;
        }
    }

In this case, an unmodified version (NULL) of empty passwords is set,
to allow reading them from the password prompt on nginx startup.

As an additional optimization, a preserved instance of inherited
configured passwords is set to the previous level, to inherit it
to other contexts:

    server {
        proxy_ssl_password_file password;

        location /1/ {
            proxy_pass https://u1/;
            proxy_ssl_certificate $ssl_server_name.crt;
            proxy_ssl_certificate_key $ssl_server_name.key;
        }

        location /2/ {
            proxy_pass https://u2/;
            proxy_ssl_certificate $ssl_server_name.crt;
            proxy_ssl_certificate_key $ssl_server_name.key;
        }
    }

It was possible to write outside of the buffer used to keep UTF-8
decoded values when parsing conversion table configuration.

Since this happened before UTF-8 decoding, the fix is to check in
advance if character codes are of more than 3-byte sequence.  Note
that this is already enforced by a later check for ngx_utf8_decode()
decoded values for 0xffff, which corresponds to the maximum value
encoded as a valid 3-byte sequence, so the fix does not affect the
valid values.

Found with AddressSanitizer.
Fixes GitHub issue #529.

As uncovered by recent addition in slice.t, a partially initialized
context, coupled with HTTP 206 response from stub backend, might be
accessed in the next slice subrequest.

Found by bad memory allocator simulation.

It appears to be a relic from prototype locking removed in b0b7b5a35.

This makes it easier to understand why sessions may not be saved
in shared memory due to size.

All such transient buffers are converted to the single storage in BSS.

In preparation to raise the limit.