Make transaction_replay work better in read-only scenarios

Overview

When readwritesplit is used with a servers that are all labeled Slave, transaction_replay will cause slow failures in cases where it is known that no replacement will ever arrive. For these cases, an additional flag that tells readwritesplit to fail immediately if a write is seen but all servers are currently Slave. This would improve how readwritesplit works in these kinds of use-cases.

Implementation

The case where a write is received but no target was found can be handled in RWSplitSession::handle_routing_failure(). In this function, all attempts at retrying of both individual statements and complete transactions can be disabled if the query is a write and no candidate is available.

This could also be implemented as a read-only mode in readwritesplit where a write will immediately cause the connection to be closed. This could be done in RWSplitSession::route_query() by checking what the target type of the query is. If the target type is TARGET_MASTER, the connection can be immediately closed. An improvement to this would be to queue a read-only error to be sent to the client. This functionality needd to generate the errors already exists for the master_failure_mode=error_on_write mode.

Original description:

The customer is requesting to add the "transaction_replay" feature to the "readconnroute" router. This would allow for transparent node failures / fail-overs between only the slaves for maxscale configuration where only "slaves with external master" and no "master" are being part of maxscale server. (as per example below)

Example:
Server │ Address │ Port │ Connections │ State │ GTID
repl2 │ 10.0.1.102 │ 3306 │ Running, Slave of External Server │ 0-1-57233
repl3 │ 10.0.1.103 │ 3306 │ Running, Slave of External Server │ 0-1-57233