Fix sentinel reconnect loop due to unresponsive sentinel

[dhruvjain99]

Specifically handle connection errors for sentinel process to prevent termination.

Fixes #75

[dhruvjain99]

@zuiderkwast Please have a look.

[zuiderkwast]

OK, I understand the problem. I have some small suggestions.

To be honest, trap_exit is not the perfect way to handle processes. It is easy to miss something. It would be better to use a supervisor. Maybe we can do that in the future...

[zuiderkwast]

When connection fails with reason econnrefused, eredis:start_link returns {error, econnrefused} and at the same time, the eredis_client exits with reason {connection_error, econnrefused}. The 'EXIT' message waits in the inbox and query_master connects to another Redis Sentinel node and stores the successful pid in conn_pid. When handle_info is called, the conn_pid doesn't match.

Is this correct?

I think we need a better way to distinguish between this 'EXIT' message and another linked process exiting. Maybe it's better to do an explicit receive {'EXIT', _, {connection_error, _}} -> ok end after eredis:start_link returns an error, just before we try the next connection?

[zuiderkwast]

Is this always an error?

When eredis is started with sentinel options and later eredis is stopped with eredis:stop(Pid), this message is logged? It's not an error. Also I don't think we should log the state. It looks like debugging.

How about instead exit with the same reason as the linked process? Then an error will be logged automatically if Reason is anything other than normal.

Suggested change

	handle_info({'EXIT', Pid, Reason}, S) ->
	?LOG_ERROR("eredis_sentinel: Exit from pid ~p with reason ~p and state ~p", [Pid, Reason, S]),
	{stop, normal, S};
	handle_info({'EXIT', _Pid, Reason}, S) ->
	{stop, Reason, S};

[zuiderkwast]

Please add some comments inside this test case to make it easier to understand what's happening.