Outstanding items for improving the automation

[natefoo]

Leftover issues and more from #21.

• [ ] Dry runs/test builds are not currently supported. For that we'll need the script to automatically delete all the histories it created during the run. So the @galaxybot test this and @galaxybot deploy this commands, as well as the automatic run that happens when the PR is opened by an "authorized" user will all deploy.
• Relatedly, run failures require deleting all histories created during that run or they will be skipped on the next run.
• [ ] We should probably switch from the no-longer-supported ghprb plugin.
• [ ] CVMFS snapshots so that indexers can run back-to-back with fetches
• [ ] Make histories public and generate a slug
• It should be possible to import builds that have completed without deleting the histories and building again.
• [ ] The entire process could run as cron jobs/scheduled Jenkins runs instead of being tied to individual PRs
• [ ] PRs adding new genomes have to be run twice (once to run "stage 0" DMs and again to run "stage 1" DMs)
• [ ] Configure MinIO object store backend on usegalaxy.org
• [ ] Running the importer in Docker (and all the double setup that goes along with it) is not really necessary, it's mainly a holdover from usegalaxy-tools so we can mount $OVERLAYFS_MOUNT as /cvmfs/$REPO. But we can use the namespace techniques used by https://github.com/cvmfs/cvmfsexec to do this without docker, which should be much quicker/simpler.
• [ ] The builder waits for CVMFS client IDC repo revision to sync, but it needs to reload the tables after the sync happens

I commented out a couple of tasks that I expanded upon in #30.

[natefoo]

Running the importer in Docker (and all the double setup that goes along with it) is not really necessary, it's mainly a holdover from usegalaxy-tools so we can mount $OVERLAYFS_MOUNT as /cvmfs/$REPO. But we can use the namespace techniques used by https://github.com/cvmfs/cvmfsexec to do this without docker, which should be much quicker/simpler.

Rather than this, I think we can remove one entire step and part of the complexity (and a point of failure encountered in #26) by simply importing directly on the CVMFS server, which has a sizable spool volume.