A passive Maxscale with cooperative monitoring should not acquire exclusive server locks

Historically, we have advised against combining the passive-setting with cooperative_monitoring_locks. In existing MaxScale versions, what happens is that a passive MaxScale can still take the locks (but not perform failover), so that routing queries will work even if no MaxScale is active. The downside of this approach is that the passive MaxScale will not relinquish the locks even when the active MaxScale comes back online. Thus, no MaxScale can perform failover if required.

With this change, the passive MaxScale will not take the locks, and will also release any locks it may have acquired previously. The assumption is that if cooperative monitoring is being used with active/passive, then someone/something is keeping track of the situation and ensures one MaxScale is always active.

Original description:
When maxscale is in mode passive:true , all monitors with cooperative monitoring should not be allowed to take locks. This means that an external script or program (e.g. Keepalived) or the DBA must ensure that one MaxScale is always active.