DOC: config: clarify req.ssl_sni

DOC: config: clarify req.ssl_sni

The req.ssl_sni fetch (as well as all other req.ssl_* fetches, which
share the same underlying parsing) only analyzes the first ClientHello
message found in the request buffer.

This is not obvious to users, and can lead to incorrect assumptions
when the value is used for routing or access control decisions:

  - if the client sends a second ClientHello within the same TCP
    stream, for instance following a TLS 1.3 HelloRetryRequest, or
    during a TLS renegotiation, that second ClientHello (and its SNI)
    is silently ignored.

  - when Encrypted Client Hello (ECH) is used, only the "Outer"
    ClientHello is visible on the wire, so the SNI returned is a decoy
    SNI and not the actual host the client intends to reach. The
    "Inner" ClientHello, which carries the real SNI, is encrypted and
    cannot be analyzed by this fetch.

Document these limitations on req.ssl_sni, and add a short pointer to
that documentation on the other req.ssl_* fetches (req.ssl_alpn,
req.ssl_cipherlist, req.ssl_ec_ext, req.ssl_hello_type,
req.ssl_keyshare_groups, req.ssl_sigalgs, req.ssl_st_ext,
req.ssl_supported_groups, req.ssl_ver).

This was reported by Daniel Birtwhistle.

This should be backported to all stable versions.