feat(app): experimental azure blob storage support

[olevski]

closes #1354

This can be merged and released. Azure blob support is disabled by default. We can simply enable it where we want it as long as the cluster already has the azure blob csi driver.

There is also some very light refactoring for the following:

• Handle mounting more than one cloud storage type.
• Use different classes for Jupyter servers on creation requests and on listing requests. This is useful because when creating a server we need to a bunch of checks that we do not really care about when simply listing an existing server.

/deploy #persist

[RenkuBot]

You can access the deployment of this PR at https://renku-ci-nb-1374.dev.renku.ch

[Panaetius]

Shouldn't we check that s3 is enabled here via config.cloud_storage.s3.enabled?

Also we should fail is both s3.enabled=True and azure_blob.enabled=True in the values file somewhere (I didn't see code for this)

[olevski]

@Panaetius for now there is no problem if both s3 and azure blob storage are enabled. And I foresee that some deployments will want to use both. Especially those running on Azure. But even non-Azure deployments can use both s3 and azure provided that they have installed the azure blob csi drivers in their k8s cluster.

The way I recognize azure blob storage is if the access key is not provided by the secret key is provided. That is the only way. It is not perfect but it should work to start. Then we can adapt the ui and have proper indication what storage type is being used. But for now we are jumping onto the same api for the s3 storage.

When the user mounts a azure blob container then the endpoint is still the azure endpoint, the bucket is the azure blob container name and the secret key is the azure blob credentials. And the public key is left blank.

So I will add the checks for what is enabled and fail if s3 stuff is provided but s3 is disabled. But we can definitely support both azure blob and s3.