Clarify bind and connect addresses throughout JupyterHub

[yuvipanda]

Currently we use ip, port, connect_ip, connect_port for various things. It's a little confusing, and not very clear what is what when reading code.

I propose for 0.9, we do the following:

1. Deprecate ip and port, connect_ip and connect_port. They'll still work
2. Turn ip and port into bind_address, which can be ip:port combo, unix domain socket, just ip, etc.
3. Turn connect_ip and connect_port into connect_address, which would do the same
4. Use this across the JupyterHub codebase, clarifying for Proxies and Singleuser servers as well.

[willingc]

+1

[Carreau]

I completely agree with that, I just didn't wanted to implement that for 0.8 with all the already existing changes. I would like to push for a non-py config files as default (traitlets works perfectly with Json), that would allow to have a command to upgrade config files.

[yuvipanda]

Yeah, I agree we shouldn't do this for 0.8. We don't really need to support unix domain sockets for 0.8 tho - our performance bottlenecks are elsewhere still (mostly in sqlalchemy blocking main thread now, I think).

[willingc]

Adding to the 0.9 milestone.

[minrk]

Since connect_ip and port will be new in 0.8, maybe we should drop those in favor of connect_address now, and add bind_address as a new concept in 0.9?

[minrk]

On second thought, I think connect_ip is a special case - Hub listening on all interfaces by having to specify a connect IP is common to all distributed deployments (even local docker), which is what prompted bringing it upstream out of DockerSpawner. Specifying anything else (connect_port, otherwise different full URL) is on a quite different level. So I'm inclined to keep connect_ip as it is now, and maybe trade only connect_port for a full connect_url (should include http[s]://), since that's brand new and only for a pretty advanced use case.