Session command response verification unnecessarily stores PS IDs for readconnroute

If a connection pool is connected to a readconnroute service and it uses the binary protocol prepared statements, some information is not cleared when the statement is closed. The result of this is first a increase in CPU usage for each prepared statement. Eventually an increase in overall memory memory usage will also be oberved but the memory is freed to the system once the connection is closed. As such, this is not a true memory leak.

When a prepared statement is executed through a service that does not have the RCAP_TYPE_SESCMD_HISTORY capability, the preparation is treated as a session command and a response is expected. This assumption is wrong as responses will not be recorded unless the RCAP_TYPE_SESCMD_HISTORY capability is set. This can be reproduced by preparing a statement and then immediately closing it while keeping the client connection open. Eventually MaxScale should run out of memory and/or take a massive amount of CPU.

The fix is simple: check that RCAP_TYPE_SESCMD_HISTORY is set before calling code that assumes it's set.

A temporary workaround is to use a dummy readwritesplit service as one of the targets of the readconnroute service. Since it has RCAP_TYPE_SESCMD_HISTORY but no servers, the capabilities from it are added to the top level service but it won't actually end up being used at all. This does introduce a constant overhead from the query classification that it ends up doing for the session command storage but this solves both the memory usage and CPU problems:

[Dummy-Service]

type=service

router=readwritesplit

user=maxuser

password=maxpwd

[Read-Connection-Router]

type=service

router=readconnroute

router_options=master

# server1 is the actual server we want to use

targets=server1,Dummy-Service

user=maxuser

password=maxpwd