The requirement was from ceph-csi to return a snapshot size.
On further discussion and looking at the CSI spec and current implementation in kubernetes and RBD integration in ceph-csi, here are reasons why this is not required for ceph-csi,
1. CSI protocol mentions size of a snapshot as an optional return parameter and further,
https://github.com/container-storage-interface/spec/blob/baa71a34651e5ee6cb983b39c03097d7aa384278/lib/go/csi/csi.pb.go#L3094-L3102
<snip>
// This is the complete size of the snapshot in bytes. The purpose of
// this field is to give CO guidance on how much space is needed to
// create a volume from this snapshot. The size of the volume MUST NOT
// be less than the size of the source snapshot. This field is
// OPTIONAL. If this field is not set, it indicates that this size is
// unknown. The value of this field MUST NOT be negative and a size of
// zero means it is unspecified.
</snip>
2. For RBD the size is currently reflected as the size of the parent image of the snapshot, we can do the same for CephFS subvolume snapshots keeping them consistent
3. Kubernetes on clone from a snapshot or clone from a volume (which will internally use a CephFS snapshot), validates that the clone subvolume size is at least as big as the source
4. ceph-csi currently does not honor the new-size of a clone, and if it requires to do so, will resize post a clone is successful
So overall, even if we return the current snapshot size based on rstats ceph-csi should retain the above behaviors as the CSI+k8s combination leverages the size stated.
For these reasons providing an alternative in prior releases for rstats is not required and this tracker can be closed.