Large batches of session commands may leave sessions alive for a long time

The fix to MXS-4981 solves the problem by forcing the DCBs to close if the shutdown has been started. This still allows session shutdown to take an arbitrarily long time if very large amounts of session commands were batched for execution. However, this only happens if the execution of one session command takes less than two seconds on the backends in question. If it takes longer than that, the session will be closed normally.

The requirement for each session command to take less than two seconds is due to a hard-coded limit in the DCB idleness check and once a DCB has been idle for longer than 2 seconds, it qualifies for being forcibly closed even if the protocol reports that it's not possible to close it.

There are two problems that must be solved:

1. The protocol only accepts two states where it can be forcibly closed. One of them is when it's completely idle and the other is when authentication has failed. There are a handful of other states in which the connection can also be closed without causing problems in MariaDB, for example when the session command history is being sent or received or when there are pending session commands being executed and a subsequent COM_CHANGE_USER is blocking the processing of further queries.
2. The idleness calculation for a single DCB only looks at its own state. The point at which the session is stopped should be the starting point of the idleness calculation for all DCBs. Using it would guarantee that a session is always closed within a fixed amount of time.