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.
This prevents empty or failed reads from updating the last_read flag which
in turn gives us the correct connection idle time when network errors
occur.
The code registered both client and backend callbacks for backend
DCBs. This caused the whole connection to hang if backend side throtting
was ever triggered.
The fix to the bug where peer certificates were validated but not required
caused the default behavior to change. The default should've changed at
the same time the fix was made.
GCloud machines has more strict access rights settings. Derect calls of
'chmod' are needed to make all configuration files (e.g. 'fwf/rules') be
accessable by Maxscale.
The Connector-C was changed to always return only the client's charset,
not the actual charset that the connection ends up using. To cope with
this, the code has to use SQL to join the default character set name to
the default collation for it which can be used to extract the numeric ID
of the charset.
The slave backend would be closed twice if it would both respond with a
different result and be closed due to a hangup before the master
responded.
Added a test case that reproduced the problem.
As long as the same thread never handles more than one fatal signal,
multiple fatal signals can be processed. This should guarantee that the
stacktrace is printed into the log while guaranteeing that recursion never
takes place if the handling of a fatal signal causes a fatal signal to be
emitted.
It was possible that the query thread got stuck and never saw the updated
insert_val. Making the variable atomic as well as sleeping in between
queries should prevent it.
