slave doesn't set status to STOPPED after max-reconnect failures

[Daniel Nichter]

Related to bug 743958 (need way to determine master status/information from slave), while testing bug 956200 (slave config file option max-reconnects doesn't work) I found that even after the slave exhausts its attempts to connect to the master, the status is still RUNNING when it should switch to STOPPED and display an error message.

To reproduce:

1. Let slave fail to reconnect max-reconnect times
2. Query the sys_replication tables and see:

drizzle> select * from sys_replication.io_state\G
*************************** 1. row ***************************
master_id: 1
   status: RUNNING
error_msg:

drizzle> select * from sys_replication.applier_state\G
*************************** 1. row ***************************
              master_id: 1
 last_applied_commit_id: 5
originating_server_uuid: 44E71752-D51E-4B34-81C9-A32AA5C97020
  originating_commit_id: 5
                 status: RUNNING
              error_msg:

[Daniel Nichter (daniel-nichter)]

The linked branch actually fixes this bug by calling setIOState(err_msg, false); if _is_connected is false after all reconnect attempts.