Add more fine grained timeout options: connect, recv

[sneako]

Right now, we pass the same value for receive_timeout, everywhere that will accept it, with no regard for any time that has already elapsed. We need update the receive_timeouts we pass by subtracting the elapsed time of any intermediate steps in order to properly respect the timeout.

[josevalim]

We may want to have two timeouts: one for each individual read/receive from the socket and one for the whole connect+request+response. Or even three: connect, individual read/receive, and whole request+response.

[sneako]

We also have the pool timeout as well, so there could be a total of 4 timeouts :) It seems like a lot but I suppose most users would just keep the defaults and only configure the ones they actually care about.

[whatyouhide]

I think having sane defaults makes up for it. I would love to be able to have this much control. :)

[sneako]

I just merged #233 which addresses the original issue, where it was possible that the elapsed time experienced by the user could greatly exceed the configured receive_timeout.

I will leave this issue open, because I would still be willing to accept changes to make the timeouts more configurable as discussed above.