Method timeouts are unpredictable

[iawells]

First up, read_timeout (passed to init) isn't a timeout on the 'read' function but a urllib read timeout, and the docstrings are not clear on that, which is how I came to read the code.

Second, it's not enough alone to control the timeout on functions. I'd like my calls to return with a 'couldn't complete' in a predictable time. The read timeout's only a part of it, and indeed setting the read timeout to 2s actually results in about 8s of waiting because there's also a bunch of retries. I think there's also a connect timeout that comes into play. Obviously, allow_reconnect also affects timeouts.

As it happens you can get to self.http and set up its retry and timeout settings, but I don't imagine that's quite how you meant it to work.

My thought is that the retry and timeout settings (as urllib offers them) could be init options, and we could document how long a call will run before failing in at least some circumstnaces.

[iawells]

Actually, I see I missed the 'timeout' param on 'read' and 'watch' as well, but same thing: if I suspend etcd, a read with a 2s timeout takes 8s, and a watch with a 2s timeout is the same. (Watches do indeed take 2s when the connection establishes properly.) If there's nothing obvious to change then documentation would help.