To Reproduce Steps to reproduce the behavior:

1. Create a share, and a snapshot of the share, and clone the snapshot into a new share
2. Delete the new share
3.  If you perform (2) fast enough, there's a clone split operation in progress in the driver, and the share deletion call fails.

Expected behavior

• Clone splits are good for performance on long living shares. However, if a newly cloned share needs to be deleted, a queued clone split operation shouldn't block the deletion

Bug impact

• Shares can be stuck in "error_deleting" status which prevents their deletion by a regular non-privileged user.

Known workaround

• OpenStack "administrator" users can reset the "status" of the share stuck in "error_deleting" and attempt deletion 
• Users can wait a while and then delete a newly cloned share, however, it is hard to say how long it'll take to complete clone splits - clone split jobs are "queued" by ONTAP, and they are executed when the ONTAP cluster has low load.

Additional context

• Launchpad Bug: https://bugs.launchpad.net/manila/+bug/1960239