readconnroute performance regression in 6.4

For a workload that consists only of large queries that receive very small responses, there's about a 15% regression in terms of performance. The best example of this kind of a workload is the loading of a database dump.

The problem can be reproduced by executing DO 'aaaaa .... aaaaa' statements that are near the 16MiB packet maximum size. As the queries do nothing on the database, the limiting factor is MaxScale.

The cause of the slowdown is the unconditional query classification that is done in ServerEndpoint::routeQuery that is used to determine whether a packet is a read or a write. This is done to be able to determine which latency histogram to insert the query timing result into but this imposes a requirement to always classify queries even if the configuration in 2.5 would not need it.

To fix it, the code should detect if the router requires query classification by checking for the RCAP_TYPE_QUERY_CLASSIFICATION bit in the capabilities. If it's present, accurately determining the query type comes at no cost. If the bit is not present, only existing information, i.e. the server state, should be used to come to a less accurate but still somewhat valid estimate of the query type. In practice this means that the query type is a write if it's routed to the primary node of the cluster and a read if it isn't.