If the protocol routes a COM_QUIT packet to the backend, it must not
generate a packet when it is shutting down. This could cause unexpected
write errors if the backend server managed to close the socket before the
write was done.
By deferring the closing of a DCB until the protocol tells that it's in a
stable state, we avoid closing the connection mid-authentication. This
makes sure that all connections have reached a stable state before they
are closed which in turn prevents the connections from counting towards
aborted connects (or failed authentications like it did with the old fix).
When a fake handshake response is generated for a connection that hasn't
received the server's handshake, the client's SHA1 would be used with a
static scramble. This, in theory, would weaken the authentication to some
extend so to completely prevent this, a null password is used. This
removes any possibility of the password being exposed.
The backend didn't expect AuthSwitchRequest packets in response to the
handshake response packets. This is allowed by the protocol and appears to
happen with at least MySQL 8.0.
If the client DCB of the session was passed into the function, it was
possible that the session pointer for it was already set to null. The
session pointer of an open DCB is never null but a client DCB's session
pointer can be null if accessed via the MXS_SESSION object.
This causes the connection failure to be counted as an authentication
failure instead of a connection error. The former never causes the host to
be blocked which effectively solves the problem for most cases. The only
case where this would not work is where the network buffer for a backend
DCB is full right after the connection is created.
The hangup and error handlers now have unique messages. Although the
behavior in the handlers is practically the same in both cases, the cause
of the error is not the same.
If a socket error is present, it is added to the error message. If an
error is present, it should clearly show the reason why the TCP socket was
closed.
The is_fake_event boolean helps distinguish fake events from real
ones. This makes figuring out the real source of hangup events easier.
The backend DCBs do not have to send hangups in the close protocol API
method. If the conditions for the hangup were true, the session was
already stopping meaning that the client DCB was already closed.
If an error is generated while a COM_CHANGE_USER is being done, it would
always use the sequence number 1. To properly handle this case and send
the correct sequence number, the COM_CHANGE_USER progress needs to be
tracked at the session level.
The information needs to be shared between the backend and client
protocols as the final OK to the COM_CHANGE_USER, with the sequence number
3, is the one that the backend server returns. Only after this response
has been received and routed to the client can the COM_CHANGE_USER
processing stop.
