Bug 2112929

Feature: Users can customise the StorageClass name(s) while creating the StorageCluster CR during the deployment of a *new* ODF cluster on *CLI* (UI not supported). The `Spec.ManagedResources.CephFilesystems`, `Spec.ManagedResources.CephBlockPools`, `Spec.ManagedResources.CephNonResilientPools`, `Spec.ManagedResources.CephObjectStores` `NFS` and the `Encryption` are the fields that can be updated in the StorageCluster CR, the user can choose to only update the fields (i.e, SC provisioner) which they are making use of and customise the StorageClass name. Ref- spec: managedResources: cephFilesystems: storageClassName: <enter-a-custom-storage-classname> cephObjectStores: storageClassName: <enter-a-custom-storage-classname> cephBlockPools: storageClassName: <enter-a-custom-storage-classname> virtualizationStorageClassName: <enter-a-custom-storageclass-name-for-virtualization-sc> cephNonResilientPools: storageClassName: <enter-a-custom-storage-classname> nfs: storageClassName: <enter-a-custom-storage-classname> encryption: storageClassName: <enter-a-custom-storage-classname> **NOTE:** The feature is mainly for *new* deployments, but if a user wants to cutomise the storageclass names in an upgraded cluster then there are a few edge cases that needs to be considered: 1. For an internal mode cluster, after updating the CR with custom storageclass names the new SCs will be created but the older one's would still exist, and it's their choice to keep or delete them as per their usage. 2. For an external mode cluster, after the deployment the user can edit the CR and add the custom storageclass names to it, but the change (new SCs) would only come into effect if the user updates the `data.external_cluster_details` field in the `rook-ceph-external-cluster-details` secret that contains the external cluster data. Reason: This will allow the user to use the same StorageClass for both internal, external mode of deployments and avoid creation of extra resources. Result: 1 StorageClass for both internal and external mode of deployment is consumed by ODF.