The current recovery logic has a mechanism to optimize recovery time on a dead master scenario:

1. If replicas are probed
2. And one is picked as candidate to be promoted (based on binlogs, version, configuraiton)
3. And it's in the same DC and environment as the dead master
4. And it has prefer (or must, which is yet unsupported) promotion rule

then, we we consider the replica as "ideal", immediately promote it as master, and asynchronously point the rest of replicas below it.

While analyzing a recent production use case, I noticed a setup where all servers were either marked as neutral or must_not. None was marked with prefer. In that scenario, the recovery was not optimized.

In this PR:

• as long as the server is not marked with must_not promotion rule
• if it has the best promotion rule from among the replicas it would own after promotion, then it's an "ideal" replica.