Add a jupyterhub/k8s-hub-slim image alongside jupyterhub/k8s-hub

[consideRatio]

The jupyterhub/k8s-hub-slim image is tested in the (stable, install) job now - it works fine and I think we don't need anything more in tooling etc, just another chartpress.yaml configuration entry.

This PR stems from a discussion in #2917 (comment). It also made me discover a chartpress bug in jupyterhub/chartpress#189.

Image size

Image	Size
(current)	413 MB
Debian slim	256 MB
Debian fat	414 MB

Image vulnerabilities

Image	Size
(current)	Total: 625 (UNKNOWN: 4, LOW: 16, MEDIUM: 131, HIGH: 454, CRITICAL: 20)
Debian slim	Total: 95 (UNKNOWN: 0, LOW: 12, MEDIUM: 39, HIGH: 40, CRITICAL: 4)
Debian fat	Total: 625 (UNKNOWN: 4, LOW: 16, MEDIUM: 131, HIGH: 454, CRITICAL: 20)

Image build time

It seems we may end up with a significantly longer build time.

Image	Size
(current)	min 1m40s, max 2m40s
Debian slim/fat	min 2m51s, max 3m53s

Conclusion

We drop 36% of the image size by removing these additional tools. In the case of using python:3.9-bullseye-slim as a base image still, we also drop a huge amount of since long unfixed known vulnerabilities.

This PR also did not add notable complexity, and I think its very reasonable to go for this since no additional tooling was required and the Dockerfile is easy to understand still etc.

For considerations on using this as default image or similar, I suggest another issue/pr is to be opened.

[consideRatio]

Do we need to document the new slim hub image somewhere, e.g. on https://z2jh.jupyter.org/en/stable/administrator/optimization.html or https://z2jh.jupyter.org/en/stable/administrator/security.html ?

@manics commented in #2921 that has this PR bundled with it.

[consideRatio]

• @manics I added some documentation in the Security section in commit 2e2369d.
• I also omitted py-spy from the slim image by removing it from requirements.in/txt and specifying it manually.
• I also added comments and refactored the Dockerfile for hub/singleuser a bit to reduce complexity of maintenance long term.

[manics]

The hub change looks fine to me. I've made some optional suggestions on wording to the docs and comments.

I've been wondering what the purpose of the singleuser image is? If it's just for testing do we need the complex optimised build process?

[consideRatio]

Thanks for your review @manics, great suggestions also!!!

If it's just for testing do we need the complex optimised build process?

Kind of, for aarch64 we need to have the python package installation or wheel building done in a base image where compilers are available as pycurl for example isn't available as a wheel for aarch64 I recall. So, we could go for a final image without slim.

At the same time, the incremental code complexity isn't soo high, because we provide the exact same build stage in the hub's docker image currently. Also the speed of building this image is higher I think. The reason is that you can do pip wheel building at the same time as you do apt installing - two stages can build at the same time assuming one doesn't have the other as a base image or leads with a statement that references the previous stage.

I'm also fond of it now as I see it as a robust pattern to promote elsewhere, and due to that, is good to have visible in more than just where its most useful.

[manics]

Thanks!