CephFS NodeGetVolumeStats procedure should accept standard staging path

The `NodeGetVolumeStats` procedure in CephFS does not handle requests for using the inital staging path correctly.

This isn't a problem with Kubernetes, as that uses the publish path by default:
```
/var/lib/kubelet/pods/d88426aa-2d97-41dd-b754-2794f97f8ba0/volumes/kubernetes.io~csi/pvc-78770630-74dd-4b6a-bef3-3e7307e5f52d/mount
```

The CSI-Addons Volume Condition Reporter uses the staging path by default, which appends `/globalmount` to the requested target directory:
```
/var/lib/kubelet/plugins/kubernetes.io/csi/openshift-storage.cephfs.csi.ceph.com/b38dba31761526eebc9b397a08986ee4dab5fa2515f8dc85bd47059ee9c8709a/globalmount
```

The `/globalmount` is not part of the CSI specification, and callers of `NodeGetVolumeStats` need to know about this Ceph-CSI specific thing.

Ideally Ceph-CSI handles `NodeGetVolumeStats` requests in such a way, that it is checked if the path was used for staging, or was used for publishing (but without the known kubelet format of the paths). A difficulty is that there should not be any checks on the path itself, as that can cause hangs (csi-addons/kubernetes-csi-addons#850).

This issue is handled in RBD with `getStagingPath()`. However, it uses `Mounter.GetMountRefs` which calls `stat` on the path. The `stat` syscall can potentially hang, and should not be called in functions that return a Volume Condition.

Start at the CephFS NodeGetVolumeStats procedure and compare its staging-path handling with RBD's getStagingPath(). Review Mounter.GetMountRefs and the warning that stat can hang, along with the CSI-Addons staging-path request context. Done means staging and publish paths are handled without path checks that can hang.

Written by the indexing model from the issue text.