Listener access logs missing %REQUESTED_SERVER_NAME% when no filter chain matches

[howardjohn]

If you are reporting any crash or any potential security issue, do not
open an issue in this repo. Please report the issue via emailing
envoy-security@googlegroups.com where the issue will be triaged appropriately.

Title: One line description

Description:
When I send a request that matches a filter chain, I see access logs:
{"requested_server_name":"hello.example.com", ...}

However, if I send a request that does not match any filter chains:
{"requested_server_name":null,...}

Repro steps:
Access log config, at the listener level:

       "access_log": [
        {
         "name": "envoy.access_loggers.file",
         "filter": {
          "response_flag_filter": {
           "flags": [
            "NR"
           ]
          }
         },
         "typed_config": {
          "@type": "type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog",
          "path": "/dev/stdout",
          "log_format": {
           "json_format": {
            "authority": "%REQ(:AUTHORITY)%",
            "bytes_received": "%BYTES_RECEIVED%",
            "bytes_sent": "%BYTES_SENT%",
            "downstream_local_address": "%DOWNSTREAM_LOCAL_ADDRESS%",
            "downstream_remote_address": "%DOWNSTREAM_REMOTE_ADDRESS%",
            "duration": "%DURATION%",
            "method": "%REQ(:METHOD)%",
            "path": "%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%",
            "protocol": "%PROTOCOL%",
            "request_id": "%REQ(X-REQUEST-ID)%",
            "requested_server_name": "%REQUESTED_SERVER_NAME%",
            "response_code": "%RESPONSE_CODE%",
            "response_flags": "%RESPONSE_FLAGS%",
            "route_name": "%ROUTE_NAME%",
            "start_time": "%START_TIME%",
            "upstream_cluster": "%UPSTREAM_CLUSTER%",
            "upstream_host": "%UPSTREAM_HOST%",
            "upstream_local_address": "%UPSTREAM_LOCAL_ADDRESS%",
            "upstream_service_time": "%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%",
            "upstream_transport_failure_reason": "%UPSTREAM_TRANSPORT_FAILURE_REASON%",
            "user_agent": "%REQ(USER-AGENT)%",
            "x_forwarded_for": "%REQ(X-FORWARDED-FOR)%"
           }
          }
         }
        }
       ]
      },

My expectation is that the REQUESTED_SERVER_NAME field would be populated here. Given tls_inspector runs before we do filter chain matching, I would expect this information is available?

[lambdai]

I guess it's because ActiveTcpListener::newConnection didn't populate the REQUESTED_SERVER_NAME.
The logic is tricky there:
If a filter chain is selected, the transport socket in the chosen filter chain should populate the REQUESTED_SERVER_NAME. The value sniffed by tls_inspector should be ignored.
If no filter chain is selected, this server name should be populated with the best knowledge, namely what tls inspector sniffed.

[howardjohn]

By the way, real world case that impacted me: I was trying to debug no filter chain match. I concluded, based on log, that client does not set any SNI. However, it actually did, but set to one that did not match any filter chain. I was only able to figure this out by swapping envoy with mitmproxy