Handle revert share to snapshot size difference

[kiran pawar]

problem
=======
Revert share to snapshot changes the size of the volume to the size it had when the snapshot was taken.

How to reproduce
================
1. Create share
2. Create snapshot from share
3. Shrink share
4. Revert share to snapshot
5. Check size on filer vs size in manila

e.g share of 10GB and reduced to 5GB by shrink operation. When revert share to snapshot is triggered, the backend driver makes share of 10GB again. But Manila share size still remains 5GB. This will be quota mismatch.

Solution (either 1 or 2)
========
1. Do not allow revert share to snapshot if there is mismatch of size between them.
2. If Share size is changed from snapshot, perform shrink/extend operation which internally handle quota management. After success of shrink/extend when size of both share and snapshot will be same, perform revert share to snapshot.

[kiran pawar (kpdev)]

@gouthamr WDYT ?

[Goutham Pacha Ravi (gouthamr)]

Thanks for raising this issue, Kiran

Two cases here wrt resizing a share after a snapshot's taken and then attempting to revert to that snapshot:

1) Snapshot size is 10GB, share size is 5 GB - reverting-in-place will need 10 GB:
- So, we can:

- Attempt a quota modification and claim the additional 5GB; if this isn't possible, we'd raise a QuotaExceeded error
- If we're able to get the extra quota accounted, we must check if the backend expects an "extend" request to be made before the revert request?

I don't know the answer to this. We must probably make an extend_share call to be safe, and it can be consistently honored across backends that implement revert.

2) Snapshot size is 5 GB, share size is 10 GB - reverting-in-place shouldn't shrink the share here. Backends must extend after reverting in case the share size is affected by the revert.