PeriodicCallback: support async/coroutine callback

[ploxiln]

#2832 plus some tests

---

EDIT: nevermind, figured out how to avoid this

ORIGINAL:

I can't quite figure out how to quiet this error log:

[E 200927 21:24:05 ioloop:910] Exception in callback <function TestPeriodicCallbackAsync.test_periodic_coro.<locals>.callback at 0x10a2a6c80>
    Traceback (most recent call last):
      File "/Users/pierce/scratch/tornado/tornado/ioloop.py", line 908, in _run
        await val  # type: ignore
    concurrent.futures._base.CancelledError

The usual pattern doesn't work:

        with ExpectLog(app_log, "Exception in callback"):
            self.wait()

even if I extend it to:

        with ExpectLog(app_log, "Exception in callback"):
            pc = PeriodicCallback(callback, 10)
            pc.start()
            self.wait()
            pc.stop()

[ploxiln]

rebased on master, latest CI matrix ran

[bdarnell]

A couple of type annotation issues here. I thought we had enough type inferencing enabled in tests to catch this but I guess not. Adding a -> None to the test_ methods might enable this.

[ploxiln]

btw, on macOS I get one more unrelated mypy warning:

tornado/netutil.py:117: error: Tuple index out of range

and it makes sense why it does not trigger in linux or windows modes:

        if (
            sys.platform == "darwin"
            and address == "localhost"
            and af == socket.AF_INET6
            and sockaddr[3] != 0
        ):
            # Mac OS X includes a link-local address fe80::1%lo0 in the
            # getaddrinfo results for 'localhost'.  However, the firewall
            # ...

[ploxiln]

rebased

[bdarnell]

call_at and call_later should have the same type signature. And I think that since they don't do anything with the return value of their argument, they should actually follow the example of add_callback and take an unspecialized Callable. (or equivalently, Callable[..., Any], which is what asyncio uses)

[bdarnell]

The change is more subtle than that: This PR adds support for native coroutines. Decorated coroutines have always been supported by the code (I think; haven't tested it. The mypy annotations would reject them but I'm pretty sure they'd still work). However, this changes their semantics: they were previously fire-and-forget (so a slow coroutine could end up with multiple copies of the task running concurrently) while now they affect scheduling (so a slow coroutine will reduce the number of calls made per unit of time).

This is a potentially breaking change so we don't want to make it by accident. I think it's probably the right move but it needs to be a deliberate decision and documented accordingly.

[ploxiln]

Native coroutines worked too, I used them for a long time, but they were fire-and-forget as you say. I'll update this to be more specific.

[bdarnell]

I think we want tests that cover the overrun behavior (since this is the part that's changing for decorated coroutines between this change and the prior implementation)

[bdarnell]

Thanks!