Fixes #2045 Timeouts should be decided with a monotonic clock

[ibygrave]

I've tried to retain Python 2.7 compatibility by using timeit.default_timer as the monotonic clock. If Python 2.7 support was not needed this change would be simpler.

[bskinn]

Python 2 support is being removed in the relatively near term, with a 3.0 release. Given that this isn't an urgent fix, I'd say go ahead and rewrite in the simpler, Python 3-only fashion, and we'll just aim it for 3.0.

Keep the current git history intact, though, so that if @bitprophet should want to use the Python 2-compatible version he can just cherry-pick from 94d840f or thereabouts.

[ibygrave]

Thanks.

For the Python 3 only version would you prefer I keep the paramiko.common.timer abstraction, or use time.monotonic directly? I'll remove the abstraction unless you have a preference.

[bskinn]

That's a call for @bitprophet -- I'll bump the question to his attention.

[bitprophet]

Re: Python 2, nah, that's going out the window RSN.

Re: whether it's nice hiding time.monotonic behind paramiko.common.timer, that's still a good question. My gut says that the way it's phrased right now - exposing the use of monotonic - is better for two reasons:

• Just less code/indirection. Always good.
• Makes it slightly more obvious to readers/contributors that "you should be using monotonic for timeout related code". I wasn't even aware that monotonic existed until reading this, though it makes a lot of sense (avoids timeouts from incorrectly firing during time changes like DST, NTP/PTP updates, etc).
  • So having this sprinkled about might clue somebody else in that "oh I should reach for this, not time.time, when I care about elapsed durations".

I'll put this in a milestone so there's a chance I'll get to it when crafting 3.0. Thanks!

[bitprophet]

Linking to #2045 (doing it in the subject doesn't work, sadly)