Publish known-good base Docker image

[JoshKarpel]

We should publish a base Docker image that can

1. Work on the CHTC GPULab machines (i.e., must inherit from the nvidia images)
2. Overrides the container entrypoint with the internal/external port goop.
3. Implements whatever TLS scheme we end up using.
4. Uses conda for Python package management.
5. Is not too big, and doesn't cause images inheriting it to become too big (hopefully...)

We may eventually have to publish two images, one for PyTorch and one for Tensorflow, though I think we'll focus on PyTorch first.

This implies we should grab the CHTC repository on Docker Hub if we haven't already.

[JoshKarpel]

If we ship a wrapper script with #6 , we may not need this. The only things we do in the current image is install packages for the demo and use an entrypoint to modify what dask-jobqueue passes in. The first should be left up to users; the second is (hopefully) functionally identical to passing our own wrapper script through the job's executable, which dask_jobqueue.HTCondorCluster does let us do (by subclassing https://github.com/dask/dask-jobqueue/blob/master/dask_jobqueue/htcondor.py#L32).

Given how annoying maintaining Docker images is, especially when they're at the top of a deep stack of FROM, I think I probably prefer the above.

[JoshKarpel]

Further thoughts: shipping the wrapper script with the package, though convenient, makes it harder to do remote submits. On the other hand, embedding the entrypoint in a Docker image is not very flexible for users.

Possible solution: once we start doing releases, we can have the job transfer the entrypoint script from GitHub (versioned by tag) with an HTTP URL in transfer_input_files. Though that means you can't start workers if GitHub is down... 🤪 . Maybe we just need to make it flexible enough to handle various ways of doing this (in the future; for now I'm going to forge ahead with script-in-package).