Loss of master lock should trigger a hangup

Currently, when cooperative_monitoring_locks is used and the master lock is lost on the current master, the server status transitions from Master to Slave. In the case where it's a transient blip, this is fine and in-flight transactions are better off being committed.

However, when semi-synchronous replication is used to guarantee that transactions are sent to at least one other slave, a network partition will cause the commit to wait for the semi-sync ACK for a potentially long time. When this happens and the monitor detects that the master lock is lost, currently the status is only downgraded and routers continue waiting for the OK for the commit. If the master ends up in the minority partition, it will eventually respond with an OK to the commit when the ACK times out. This is a problem as it means that an OK for a commit was returned that will be potentially lost when the network partition is over.

One way to solve this would be to trigger a hangup for the master if the master lock is lost with cooperative_monitoring_locks=majority_of_all. This would guarantee that if the semi-sync timeout is set high enough that MaxScale will always detect a network partition before the ACK times out, it will guarantee that the client will never receive an OK for a COMMIT from the minority network partition.