ReplicationThreadState: multi-valued logic

[shlomi-noach]

Fixes #763

Until today, replication thread state was a boolean: true when running, false otherwise. However, a IO thread could also be in a Connecting state, which is neither running nor stopped. And this state, as described in #763, can lead to wrong assumptions.

This PR introduces multi-valued logic. ReplicationthreadState is introduced, which can be:

• ReplicationthreadStateStopped
• ReplicationthreadStateRunning
• ReplicationthreadStateOther

In this initial commit, most critical existing logic has been converted to use these states as opposed to relying on a boolean value.

There's more places in the code to modify, in next commits.

cc @ggunson

[shlomi-noach]

Added ReplicationThreadStateNoThread state, to strictly identify the case of a master: no replication configured.

[ggunson]

Just to clarify the purpose of #763:

#763 is not solely about the fact that the IO thread can be in the "Connecting" state, but that the logic of determining the replication status was incomplete.

If true is

(SQL_Running=Yes) && (IO_Running=Yes)

Then the opposite of that, based on the distribution rules of negation, is:

!((SQL_Running=Yes) && (IO_Running=Yes)) = !(SQL_Running=Yes) || !(IO_Running=Yes)

This then leads to all the states that the logic would say replication is stopped:

1. IO_Running=No
   SQL_Running=No

2. IO_Running=No
   SQL_Running=Yes

3. IO_Running=Yes
   SQL_Running=No

4. IO_Running=Connecting
   SQL_Running=Yes

5. IO_Running=Connecting
   SQL_Running=No

6. (Anything else I might've missed?)

And that was the concern, more than just the extra value that Slave_IO_Running can be. This PR looks like it's dealing with all of that so far; this is just to document the extent of the reasoning for anyone reading this.