TLS 1.3 version intolerance is rampant and the TLSWG did not agree to change the versioning scheme, so we must repeat a fourth time the song and dance that didn't work well the first three times either. :-(

This time, we should try to make the fallback less damaging than before.

1. Communicate to BoringSSL that, although the maximum version is TLS 1.2 on fallback legs, the true maximum version is TLS 1.3. In particular, this means we will enforce the 1.3 downgrade indicator. This will serve as FALLBACK_SCSV (though we may as well do that too).

2. Implement the fallback in SSLConnectJob instead of HttpNetworkTransaction. The metrics will be per-connection rather than per-request, but we won't bifurcate the socket pools and cause mmenke@ sadness. The cipher metrics were already per-connection, so it seems to have been fine.

3. Be very selective on the fallback trigger. This will take some care and experimentation. One of the many many failures of the fallback of yore was that we masked new implementation bugs. The TLSWG's bad decision forces us continue this practice, but let us try to minimize the damage on the ecosystem.

Previously, I had hoped we could condition this on whether we failed at ClientHello or later, but we have found 1.2 servers which correctly accept a 1.3 ClientHello with a 1.2 ServerHello but fail much later on Finished. (They probably feed a 1.2 ClientHello into the transcript, but I have not confirmed.)

Thus we will need something weaker. If we got to the ServerHello AND the ServerHello reports TLS 1.3, do NOT fallback. Intermittent 1.2 bugs will still be masked, but autoreload probably masked them anyway. Hopefully there are no servers which respond to a 1.3 ClientHello with a 1.3 ServerHello while still speaking 1.2.

We may also try conditioning on the exact alerts. ERR_SSL_PROTOCOL_ERROR is a rather wide net.

4. Measure measure measure so we can get rid of this.