Fixups for 9.2

See commit log for details on changes.
Good point. There are actually THREE different things to consider: How the INADEQUATE_SECURITY condition is detected, how INADEQUATE_SECURITY is sent, and whether fallback is done. I agree that false start isn't a factor for when it is safe to send INADEQUATE_SECURITY. However, it *is* a factor in the detection step, which precedes the sending step. That is, you don't want to detect/save the inadequate security bit for a server unless/until the full handshake has completed; otherwise, you would use that saved bit during your next (fallback) attempt.

To put it more concretely, in the case of NSS, it is OK to save the INADEQUATE_SECURITY bit for a server in the handshake callback, but not in the false start callback or the protocol negotiation callback. OTOH, hopefully you would never get to the handshake callback in the first place, because you really should have killed the connection earlier.

The side-effect of this is that, if one wants to do fallback, one MUST complete the handshake when inadaquate security is detected, instead of terminating the TLS handshake earlier, even though terminating the TLS handshake earlier is the superior thing to do otherwise. That's another reason why explicitly allowing the fallback to HTTP/1.1 here is bad.