Should set old master's read_only to false under DeadCoMaster failure

[ZhangJiaQiao]

There is an attempt of setting old master's read_only to false while recovering DeadMaster failure, but there is no such operation for DeadCoMaster failure, which is not reasonable. See the code below:

DeadMaster

orchestrator/go/logic/topology_recovery.go

Lines 920 to 928 in 1a6c3cd

	{
	_, err := inst.SetReadOnly(&promotedReplica.Key, false)
	AuditTopologyRecovery(topologyRecovery, fmt.Sprintf("- RecoverDeadMaster: applying read-only=0 on promoted master: success=%t", (err == nil)))
	}
	// Let's attempt, though we won't necessarily succeed, to set old master as read-only
	go func() {
	_, err := inst.SetReadOnly(&analysisEntry.AnalyzedInstanceKey, true)
	AuditTopologyRecovery(topologyRecovery, fmt.Sprintf("- RecoverDeadMaster: applying read-only=1 on demoted master: success=%t", (err == nil)))
	}()

DeadCoMaster

orchestrator/go/logic/topology_recovery.go

Lines 1440 to 1443 in 1a6c3cd

	if config.Config.ApplyMySQLPromotionAfterMasterFailover {
	AuditTopologyRecovery(topologyRecovery, fmt.Sprintf("- RecoverDeadMaster: will apply MySQL changes to promoted master"))
	inst.SetReadOnly(&promotedReplica.Key, false)
	}

Old master is supposed to be dead and should not accept new write requests. If we don't try to set old master's read_only to false and the master is not dead completely, there might be living connections still accepting new write requests. When there is only one master is allowed to accept write requests for some purposes, such as generating auto-increment id for new records, the living connections of the old master might still accept new write requests and its data will be conflict with the new master's.