Replace tornado options with traitlets

[rcthomas]

Here is a pass at what replacing tornado options with traitlets might look like. Also,

• Adds an option to specify a loadable configuration file.
• Adds an flag that causes the application to print a default config file and exit.
• Preserves command line arguments with a set of aliases.
• Uses a traitlets default decorator to set the default cull_every to timeout // 2.

Using traitlets would provide a familiar way for JupyterHub admins to introduce additional logic in handle_server(), through a hook that could be defined via service configuration file. Related to issue #44 and issues referenced therein.

Note this PR doesn't try to introduce a hook for that kind of configurable logic, it just changes tornado options to traitlets. Can we discuss:

• Is this more or less the kind of thing we'd need to do?
• Does this break backwards compatibility...? At first glance it doesn't seem to.
• Does the additional logging stuff traitlets brings in present a problem?

[manics]

I haven't reviewed the changes yet, but I support moving to Traitlets. It'll help with adding extensibility, which has been discussed in a few issues including:

• Support custom culling logic through hooks (like Spawner's pre_spawn_hook etc) #25
• How configurable should the culler be? #9

Since we can let people install their own extensions, and initialise them in jupyterhub-idle-culler by passing the parent object to them.

[yuvipanda]

Absolutely love it!

[yuvipanda]

This... looks ready to go? What else is missing?

[rcthomas]

@yuvipanda I marked this as draft because I threw it together in a hotel lounge while on travel and then haven't been able to get back to it. But I thought it might be helpful to at least get a version of it out there as a proposal for people to look at and see if there was anything obviously missing in terms of making sure the CLI looked compatible with the old one, etc.

I did have a question about logging and I see #84 has popped up, related. We could try to reconcile that here or do it as a later pull request (one thing at a time...?). In any case I am interested in whether folks think this is a better move than going with argparse. I think traitlets has the upside of configuration and familiarity within the JupyterHub domain.

[manics]

We don't need to do everything in one go as long as we don't introduce any major problems, and resolve any issues before a release. I'm in favour of getting this in and dealing with logging in a separate PR.

[rcthomas]

What was bothering me here ended up just being the default log level when you switch to traitlets is warning, not info (which is what idle culler was using before). Leaving that be just didn't sit right with me, and it was fairly simple to just make the traitlets logging work so I went ahead with that. Sorry for the hold up.

[rcthomas]

Should address #84