When TLS 1.3 is used and `fail_if_no_peer_cert` (or equivalent)
is configured on the server, such as in mTLS scenarios, and
the client certificate is missing or invalid, the TLS 1.3 alert
will be sent after the handshake has completed.
The same is true for post-handshake authentication in TLS 1.3
which Erlang/OTP doesn't yet support, but will at some point in
the future.
Due to the asynchronous nature of some `ssl` socket operations,
such as sending, the alert may not always be returned from a
socket call. When the ssl socket is active we would receive
it as a message instead, so when Gun gets `{error,closed}`
it must look for the active message and see if an alert
occurred. When the ssl socket is passive we don't, so we
must query the socket for it (trying to set the socket active
at that point gets us the alert in the return value). There
is a span between handshake and the initial active mode set
where the socket is passive and may send data (the HTTP/2
preface) so we must account for both cases.
Because we sometimes have to wait for the alert as a message,
and we don't want to wait for a very long time (200ms), we
sometimes may lose the alert. Perhaps in the future this wait
time can be made configurable for users that really require
getting the alert.
The tests are only enabled on Linux because other OSes have
intermittent failures (likely due to timing).