Allow for dynamic image building on VEDA Hub

[batpad]

Somewhat related to #5

Previously, if users needed dependencies or an image that was not already available in the JuypyterHub profile options, they had to figure out building that image, and then contact an "admin" to get their image added to the profile choices on VEDA Hub. Also, updating dependencies, etc. had the potential to break existing work-flows.

Last year, we implemented a feature on JupyerHub where users are able to specify an arbitrary image name and tag, and have their JupyterHub session started using the custom image. This has been useful in allowing users to test newer versions and manage dependencies without being blocked by a Hub admin adding their image to the list of choices.

This still requires users to know how to build a docker image and push it somewhere so that it is available to be used on the Hub. There has been a significant amount of work already done to integrate a "Binderhub-like" experience inside the kubespawner frontend. The idea here is that users would just be able to specify a Git repository from which they wish their environment to be built. The backend would then use repo2docker to read requirements specified in the repository and build the image dynamically and use it to start the user's Jupyter environment.

2i2c has an excellent blog-post of the rationale behind this feature and the work done so far to implement it: https://2i2c.org/blog/2024/jupyterhub-binderhub-gesis/

The main work remaining is to improve the frontend experience for users, to be able to see logs of the image build process, etc. Working on frontend here would also allow us to start looking at improving the kubespawner frontend overall - the kubespawner frontend is the entry-point for users into the Hub and is currently very hard to maintain or extend old-school HTML and javascript. Modernizing the frontend would give us a lot of flexibility and allow us to improve the overall user experience as they enter the Hub.

The scope of this ticket would be to look at the code for jupyterhub-fancy-profiles, add design inputs, ensure the frontend code follows best practices for a React application, and bring it to a state where it can be upstreamed and made default in the kubespawner frontend. Down the road, we may want to extend this into looking more closely at the design behaviour of the kubespawner frontend and tailoring it for a better user experience.

cc @yuvipanda @ranchodeluxe @wildintellect @j08lue

[wildintellect]

Once again have a look at wholetail.org which used repo2docker, the biggest flaw was the documentation. That and it's no longer actively maintained. https://wholetale.readthedocs.io/en/stable/users_guide/customizing.html#customizing

The biggest thing missing in this space is actually a code analyzer that can figure out from what you've written, what to put in the conda/toml file, and if it should be frozen at specific versions.

[batpad]

To add here, this issue goes a bit beyond just dynamic image building, but would also allow users to better share links to reproducible environments + notebooks, once we have this setup: i.e. we could take in query parameters that defines both the "environment" for the user, as well as the notebook content that needs to run, to be able to give users reliably reproducible URLs to share notebook content. This seems critical to better workflows to enable sharing of notebooks in a way that is actually reproducible.

[yuvipanda]

A useful intermediate step here is to just have https://github.com/yuvipanda/jupyterhub-fancy-profiles be good enough to be deployed on VEDA for the nicer UI. Probably a different ticket though.