Try defining volumes and volume mounts as dict

[sunu]

Trying out suggestions from #6010 (comment)

Haven't tried this out live yet, because I'm having some trouble logging in to the MAAP staging hub.

But if I understand correctly, we will run into issues without upstream changes because of how extraFiles is handled. This expects the KubeSpawner.volumes and KubeSpawner.volume_mounts to be lists. Similarly extraVolumes / extraVolumeMounts handling also expects KubeSpawner.volumes and KubeSpawner.volume_mounts to be lists.

I have tried this out on MAAP staging and it seems to work as expected.

[github-actions]

Merging this PR will trigger the following deployment actions.

Support deployments

No support upgrades will be triggered

Staging deployments

Cloud Provider	Cluster Name	Hub Name	Reason for Redeploy
aws	maap	staging	Following helm chart values files were modified: staging.values.yaml

Production deployments

No production hub upgrades will be triggered

[sunu]

Not sure if this the best approach to fix visibility of stale group shared folders. Please let me know if there's a better way to do this.

The concern is: If a user previously had a shared group folder mounted (e.g., to /home/jovyan/shared-group/<group-folder>), their underlying home PVC (<home-pvc>/<user>/) might now contain a persistent directory at shared-group/<group-folder> that was created by Kubernetes as a mount point.

Later, if the user is no longer in that group, the specific mount for the actual shared data is removed. However, the shared-group/<group-folder> directory within their personal PVC home will still be visible (as part of the main /home/jovyan mount). This can lead to confusion, showing outdated or empty folders for groups they no longer have access to.

[sunu]

The test is failing because the jupyterhub chart expects singleuser.storage to be defined as an object but we are intentionally setting it to null.