[MRG] Add a handler to expose what versions this hub uses

[betatim]

This adds a /versions handler that serves the version of BinderHub and the build image. I'm thinking this would be useful to have when there are multiple hubs in a group where either the traffic distributor (redirector) wants to know if a hub is up-to-date or if you are running a hub (like pangeo) and want an easy way to know if you are current wrt a different hub (like mybinder.org).

One problem with the current prototype is that it uses the BinderHub version defined in binderhub/_version.py which is Ok but it isn't precise enough given we hardly ever make releases. I'd like to be able to serve the git SHA1 as well (or the tag of the docker image of the hub). The problem is that I am not sure what the best way to get that information is.

Ideas:

• use something like versioneer that has 1000 lines of code to work this out (dislike versioneer)
• pass in the tag from outside/the helm chart as environment variable (dislike reading "magic" env variables)

[arnim]

I like that, but I would like to add a minor comment. Given that not at each new deployment all images are purged it is still not certain that what launches at mybinder.org successfully does so as well at a different.binder.org. Would it make sense to also link to a list (repoURL, CommitHash) of build images alongside (maybe the archive does that already for mybinder)? This could potentially also be used to reduce the time a user has to wait for a build to be ready if used in a future redirection mechanism.

[betatim]

Can you create a new issue to track the idea of a hub publishing which (repo, commit, repo2docker version) triples it has in its build cache? I think it is an interesting idea but I don't want to tackle that as part of this PR.

I'd leave publishing/coordinating when the build cache is expired to humans for the moment as it only happens once every few months and it is quite tricky to know when the build cache was last expired. You'd have to scan all images in the registry or something like that?

[minrk]

Versioneer's a popular, standard tool in Python packaging for doing exactly this, so if we want to use git info in the version, I think it's the right tool for the job. If we don't use it, then we are presumably going to end up reimplementing it instead, minus the edge-case handling it's accumulated over the years. I don't feel that the number of lines in an auto-generated file we don't need to ever look at is particularly relevant.

If folks do prefer to reimplement it, then IPython has an old implementation, runtime here and build time here.

How would we like our own implementation's behavior to differ from versioneer's?

[betatim]

I'll go ahead with using versioneer for now. The reason I was hesitant was that there was some grumbling over using it in repo2docker so wanted to check first.

[betatim]

I think this is ready to go now.

One thing I've seen while running the tests manually with pytest -svx -m "not auth_test" binderhub/tests/test_main.py::test_versions_handler is the following:

================================================================ 1 passed in 1.82 seconds =================================================================
Future exception was never retrieved
future: <Future finished exception=StreamClosedError('Stream is closed',)>
tornado.iostream.StreamClosedError: Stream is closed

I am not really sure how to track down where this is happening. It was already appearing before I made these changes so it is unrelated.