DXHTTPRequest retry loop: obey timeout

@psung, please take a look.
IMO it's better to preserve the simpler semantics of passing the unmodified timeout value to requests (which then sets it on the socket) than it is to change it to ensure that we spend no more than `timeout` before returning (which is not a guarantee that the caller can fully rely on anyway, since it's not anything like a real-time system). The scenario of the first few requests returning quickly and the last one hanging (which is necessary to trigger the scenario of significantly missing the timeout deadline before returning) seems far-fetched to me. I agree there is a minor correctness issue, but the two applications of the timeout value really deal with different issues: the one passed to requests and set on the socket takes care of stalled out requests, while the one checked in the retry loop takes care of breaking out of the 503 retry-later mode.

(We may also want to investigate using urllib3's retry support, which was introduced over the course of 2014. Maybe it better deals with this socket/total timeout duality?)