Plans for Tornado 5.1 and 6.0

[Ben Darnell]

Our next couple of releases are coming (relatively) soon after 5.0.

Tornado 6.0 will be the release that drops support for Python 2, and also removes a lot of legacy callback-based interfaces. Tornado 5.1 will mainly be about preparing for 6.0 by adding deprecation warnings to everything that's going away. My goal is that if you can run your application on Python 3.5+ and Tornado 5.1 without hitting any deprecation warnings (enable deprecation warnings by setting the env var `PYTHONWARNINGS=d`), you'll be able to move to 6.0 with no additional code changes. It should be possible for most applications to support Tornado 4 through 6 in a single codebase without difficulty. 

The major goal here is to allow Tornado to use native coroutines (`async def`) internally. This leads to several different areas that will need to change:

- Native coroutines don't know anything about the tornado.stack_context module and it would be broken by this move. Since stack contexts aren't as important these days (ExceptionStackContext is completely unnecessary with coroutines. Non-exception StackContext is harder to replace, but no good options are available until `contextvars` is introduced in Python 3.7), we're going to remove the stack_context module completely. 

- Since callback-based interfaces in Tornado tend to rely (explicitly or implicitly) on stack context for error handling, leaving them in place while removing stack contexts would introduce subtle bugs. So nearly all callback-based interfaces are gone too.

- Finally, WSGIAdapter and WSGIApplication are not really compatible with increased use of native coroutines internally, so they're also going away (WSGIContainer will stay).

One change that's not directly related to the above is that I'd like to change the behavior of `AsyncHTTPClient.fetch(..., raise_error=False)`. That currently suppresses all errors; I'd like to change it to only suppress the HTTP errors raised for non-200 status codes (but others like a failure to connect or timeout would always be raised). This would allow for the implementation to be streamlined a bit by simplifying the relationship between HTTPResponse and HTTPError.

I've put up an early draft of release notes detailing everything that's getting deprecated: http://www.tornadoweb.org/en/latest/releases/v5.1.0.html

-Ben