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.

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

The good news is this probably explains a lot of the timer oddities we
see under libuv (see detailed comments in the code). The bad news is
it means we need to rethink some things for libuv.

Test all backends that are supported with the full test suite in a
single run. We have a high setup overhead, so not only does this
reduce the number of jobs, it hopefully reduces the overall time
taken, while actually increasing the number of tests run.

Support for Python 3.7

No new unexpected failures.

Rename the 'async' methods and classes to 'async_'. I couldn't think
of a better name. But keep the old names available for BWC. Fixes #1047.

Request more specifics.

Explicitly close IO watchers 

Disable PyPy+libuv on Windows again, still some very strange errors there. But PyPy+libuv on darwin/posix works, and CPython3.6 Windows works. Perhaps the issue is the 32-bit pypy on windows and the way it adjusts socket.fileno()?

Hopefully solve the test__os issue. It turned out to be that calling uv_close at random GC times is a very bad idea under libuv. See the comment. Try enabling pypy+libuv on posix and windows; it's working on darwin for me.

By closing them when we're done, we can remove reliance on GC to clean
up multiplexed watchers and solve problems for PyPy and Windows (and
probably eventually simplify the handle cleanup we were doing.)

This makes many more tests on PyPy pass on Darwin; down from a score
of failures to about 4, but a baffling 4. test__os:TestOS_nb times
out; investigation shows that both the read and write sides of the
pipe are waiting on events, both are in libuv, and the write side
should be writable, but it's not getting an event. Not clear why this
is. I also see it with CPython 3.6, and I don't think I did before.