Alternative way of handling reconnection

This is an alternative version of the reconnect.

Even though etcd "/machine" call will always return all cluster nodes, previously failed or not, simply banning the nodes could result in funny situations. See the TestClusterFunctions.test_reconnect_to_failed_node() If we just ban some nodes, reconnection to the cluster might never happen again, even when some nodes recovered.

To avoid this, I added a flag to re-request a fresh host list from etcd and cache it back again, if some previous request failed. In the worst case scenario, the library will retry all nodes in the cluster before giving up, but won't get caught in an infinite loop (I guess).

I've also refactored the actual usage of urlib3 within client.api_execute, and extracted it to another method, this will simplify unit test mocking later. I think it also makes sense to extract the code dealing with the response to an internal method, but as I'll have to change lots of units test, I'll postpone that change. 

@lavagetto do you think this is the expected behavior for the API?