Using Redis sentinel, some commands 'send' hangs

[jgwinner]

Describe the bug When using Redis sentinel - 1 master, 2 duplicates, 3 sentinels - I can always connect to the (curent) writeable master.

However, if I 'stop' that service, the next command hangs.

This may not be a bug, maybe it's proper use of Sentinel, but if this is the case the examples and/or docs should probably be updated. I can do a PR if that's the case.

To Reproduce Steps to reproduce the behavior:

1. Implement Redis Sentinel

2. Connect to the current master

3. Issue an 'lpop' command:

   redisClient->lpop(GetQueue().toStdString(), [&webReply,&bError](cpp_redis::reply& charRequest) {
                     .... stuff ... 
       });
   redisClient->sync_commit(std::chrono::milliseconds(5000)); 

4. It works fine.

5. stop the current master. The slaves will fail over and promote a new master.

6. The next 'lpop' command hangs down inside this routine:

   
   client::send(const std::vector<std::string> &redis_cmd, const reply_callback_t &callback) {
   std::lock_guard<std::mutex> lock_callback(m_callbacks_mutex);
   __CPP_REDIS_LOG(info, "cpp_redis::client attempts to store new command in the send buffer");
   unprotected_send(redis_cmd, callback);
   __CPP_REDIS_LOG(info, "cpp_redis::client stored new command in the send buffer");

**Expected behavior**
I would think issuing any serial commands to a connection that can't take it should result in a tacopie or cpp_redis error being thrown. 

**Possible workaround**
My routine that does the connect DOES immediately exits out:

LOG_INFO << "Connecting to HA Redis servers with " << iSentinels << "sentinels";
bool bDisconnect = false;
redisClient->connect("ourcluster", [&bDisconnect](const std::string& host, std::size_t port, cpp_redis::connect_state status) {
    if (status == cpp_redis::connect_state::dropped) {
        LOG_INFO << "Client disconnected from " << host.c_str() << ":" << port;

The 'dropped' fires right off, so I could assign a bool value, and then in the outer loop, before every command check to see if we're disconnected - but that seems like a lot of potential boilerplate code.

I guess I could also just try to reconnect inside the 'connect' callback? Is that the right way to do it? The code example didn't show this

**Desktop (please complete the following information):**
 - OS: [Windows 10]
 - Browser [n/a]
 - Version [Current]

[jgwinner]

Anyone?