The code handling a master that turns into a slave or the contrary was
improved in order to avoid repeating the same operations. Also
the readability and conceptual simplicity was improved.

It's just a simpler way to CLUSTER DELSLOTS with all the slots as
arguments, in order to obtain a node without assigned slots for
reconfiguration.

Redis Cluster can cope with a minority of nodes not informed about the
failure of a master in time for some reason (netsplit or node not
functioning properly, blocked, ...) however to wait a few seconds before
to start the failover will make most "normal" failovers simpler as the
FAIL message will propagate before the slave election happens.

Also, a few nearby comments improved.

See the function top-comment for info why this is useful sometimes.

Also don't check for NOADDR as we check that node->link is not NULL
that's enough.

That's trivial as we just need to increment the count of masters that
received with an ACK.

However the failover is yet not really performed.

However currently the control is passed to a function doing nothing at
all.

This message is sent by a slave that is ready to failover its master to
other nodes to get the authorization from the majority of masters.

Also the NEEDHELP Cluster state was removed as it will no longer be
used by Redis Cluster.

If we have a master in FAIL state that's reachable again, and apparently
no one is going to serve its slots, clear the FAIL flag and let the
cluster continue with its operations again.

This is the unix time at which we set the FAIL flag for the node.
It is only valid if FAIL is set.

The idea is to use it in order to make the cluster more robust, for
instance in order to revert a FAIL state if it is long-standing but
still slots are assigned to this node, that is, no one is going to fix
these slots apparently.

Usually we try to send just 1 ping every second, however when we detect
we are going to have unreliable failure detection because we can't ping
some node in time, send an additional ping.

This should only happen with very large clusters or when the the node
timeout is set to a very low value.

If we are a cluster node the DB content will not match our configured
slots. Don't do the check at all.

There are pathological cases where the line can be even longer a single
node may contain all the slots in importing/migrating state.

adding check error code