tls_inspector: SNI not populated to `REQUESTED_SERVER_NAME` for failed TLS handshakes

*Description*:
I initially reported issue https://github.com/envoyproxy/envoy/issues/42869 to ask for the SNI being logged also for failed TLS handshakes, which GREATLY improves debugging and operations of Istio Gateways.

@agrawroh was so kind to implement this via https://github.com/envoyproxy/envoy/pull/42871,
which was then reviewed by @kyessenov, @botengyao and @yanavlasov.

I just upgraded to Istio 1.29.1, which uses Envoy 1.37, expecting that this would not populate the
`requested_server_name` in case of TLS handhake errors.

*Repro steps*:
But it seems it does not work (in the cases I tested):

1. Good case using TLS 1.2 `curl -v https://myservice.example.com --tls-max 1.2`

```
downstream_tls_cipher: ECDHE-RSA-CHACHA20-POLY1305
downstream_tls_version: TLSv1.2
requested_server_name: myservice.example.com
response_code: 200
```

2. Bad case forcing TLS 1.0 (not allowed by Envoy config): `curl -v https://myservice.example.com --tls-max 1.0`

```
downstream_transport_failure_reason: TLS_error|error:1000042e:SSL_routines:OPENSSL_internal:TLSV1_ALERT_PROTOCOL_VERSION:TLS_error_end
response_code: 0
```

^^ no value for `requested_server_name` :-(

*Admin and Stats Output*:

*Config*:

```
accessLogFormat: |
[...]
"downstream_transport_failure_reason": "%DOWNSTREAM_TRANSPORT_FAILURE_REASON%",
[...]
"requested_server_name": "%REQUESTED_SERVER_NAME%",
[...]
"response_code": "%RESPONSE_CODE%",
[...]
```

*Logs*: