Consider providing one hub per class

[yuvipanda]

In discussion with @a-adhikari about #1965, she pointed out a very useful parallel.

All other instructional platforms are compartmentalized by class – bCourses, CalCentral, Gradescope, OKPy; even Piazza can be restricted to staff and enrolled students and often is. Not even faculty, let alone course staff, have access to the platforms of other classes. If JupyterHub is going to be a platform used by multiple classes, it's natural to ask what it takes for it to have the same feature.

This makes sense from an organizational & UX perspective. It helps sidestep a number of issues:

1. Only people who are enrolled for that term in that class (via bcourses) get access to the hub for that particular class. We could possibly also determine admin access from this, although it isn't necessary.
2. Home directory archival policies become easier - if you aren't enrolled in that class for that term, you can't access your home directory anymore. Please download it before class ends (with some grace period?). This will match what they see in bcourses, I think? If not, we can do whatever it is that bcourses does.
3. We can actually tell which classes are using the hub seriously!
4. Per-class image customizations are possible (if needed). This lets us be more compact about which classes need what libraries, and remove the libraries when no longer needed.
5. Private repositories for nbgitpuller also become easier, since we can provide the private key to just that hub.

We can still keep the current hubs (datahub, r.datahub, etc) for general use. But we can remove all admin access from there - except perhaps staff (not course staff). The moment someone in a class wants admin access, we can make them a new hub.

The pain points there will be:

1. Supporting many hubs is challenging technically, with the setup we have now. Provisioning HTTPS certificates, DNS, home directory storage, etc have to be done manually. This needs to be fixed.
2. We don't have technical capacity to create / delete hubs per-class. This would need to be done automatically, or via a simple web interface that's usable by non-infrastructure staff.
3. Image updates are complicated if we allow an explosion of them, one per class. We should figure something out for this too.

These are all fixable problems. This would be great for long term sustainability, I think.

We could build this through Spring 2021, and deploy it for Fall 2021.

[choldgraf]

I think this question comes down to: is it less work in the short/long-term (both for dev and maintenance) to build functionality to serve multiple groups of people in one hub, vs. to make it easier to deploy/customize multiple hubs with potential connections between them. I think it'll require either re-working a lot of how hubs are structured, or it'll require building new technology to manage federations of hubs relatively easily. I think both could be quite valuable!

[ericvd-ucb]

The threshold could also be when a class requires undergrads as admins then a new hub is advised. Could be a useful dividing line to start with.