Prepared statements should never be removed from session command history

If a client prepares more prepared statements than can fit into max_sescmd_history, they get pruned off due to them being treated as normal session commands. This causes a problem where a reconnection inside MaxScale to one of the backend servers will cause some number of open prepared statements to be lost which will cause Unknown prepared statement handler errors in MaxScale.

The workaround that has been documented is to increase max_sescmd_history to a high enough of a value that all of the stored prepared statements fit into it plus some overhead for whatever SET command the program may execute. However, while this is something that can be avoided by correctly configuring MaxScale, it's not something that the end user should ever have to care about as it's very deep in the protocol level of how things work: it breaks the principle of MaxScale behaving exactly like MariaDB.

The solution to this is to not treat prepared statements as something that need to follow the limit of max_sescmd_history and only remove then when the corresponding COM_STMT_CLOSE arrives.