Refactor xheaders configuration

[bdarnell]

Xheader usage should not just be on or off, but specify which headers are expected (so an outsider can't spoof the one your proxy doesn't touch). For advanced usage (i.e. multiple layers of proxies) it might be nice to allow selection of a different value from the X-Forwarded-For list.

[lilydjwg]

What do you think about a user-provided function to inspect and modify the HTTPRequest as it sees appropriate?

I run into this again because I'm going to implement rate limiting for a service behind Cloudflare.

[bdarnell]

Yeah, the solution here needs to be flexible enough to support user-supplied code for this; we won't be able to support all the possible options internally. (although I think we can do some of them: instead of xheaders=True, use xheaders=('X-Real-IP', 'X-Scheme'))

In theory, this is what the tornado.httputil.HTTP*Delegate interfaces are for: you should be able to wrap your Application in a delegate that will do this transformation for you (what WSGI would call "middleware"). I'm pretty sure you can do this today without any access to Tornado internals, but there's a lot of boilerplate. Maybe we could have some sort of factory to construct the necessary delegate from a function that transforms the request or headers.