[skip appveyor]

GEVENTSETUP_EV_VERIFY has to be set when gevent is compiled. Move it from the 'leaktest' target down to where we call develop

This lets us start using our infrastructure for flaky timeouts.

Make Timeout._start_new_or_dummy stop forcing the issue.

The failing test_telnetlib was fixed by avoiding a zero-duration timer. On libuv zero duration timers can block the event loop.

libev follows libuv by not updating the loop time in a timer by default. A Timeout that we use internally still does this though.

correct a typo in src/gevent/greenlet.py
[skip ci]

Let the Timeout class update the loop time when used internally. Otherwise, test_telnetlib.py 'hangs'. Not exactly clear why, but at a guess apparently we're not getting out of the timer callback loop.

libuv: do not update the loop time when timers are started by default. See #1057. libev might follow suite in the future.

But see the comments in the code and the comments in the issue. libuv
has very different timer behaviour than libev.

It depended on when the timer expired relative to when we intered the
loop for the first time. It could still run before our other callbacks
did if it had expired before we entered the loop.

I suppose that going to the static 'extern' functions changed the
timing of things enough that this exposed itself.

I'll need help to reproduce them.

But temporarily add some extra debugging to the makefile to see if we
get a clue.

The cpython failure in test_subprocess.py definitely began with this
branch (which doesn't make much sense). The PyPy failure was happening
long before.

Skip that one test that fails on Python 3.7 under libuv on Travis. It doesn't fail for any other CPython version there and it doesn't fail locally. Chalking it up to a alpha issue for now.

Instead of manually having it schedule callbacks, we instead run
callbacks at a time in the event loop cycle equivalent to when libev
runs them. We do this with a check watcher (instead of a 0 duration
timer).

Fixes #1058