VM snapshot merge on KVM can leave volume.path in DB pointing to a file that no longer exists (multi-disk VMs)

Summary:
When deleting a VM snapshot on KVM for a VM with more than one disk, each disk's data gets folded back into its real file one at a time, but CloudStack only gets a single "succeeded or failed" answer for the whole set. If an earlier disk's fold finishes for real but a later disk's then fails or times out, the whole thing is reported as failed, so CloudStack never updates its record for the disk that actually finished. Its database is left pointing to a file that no longer exists, with nothing to catch or fix this later. The VM then fails to start with "Can't find volume:", and the only current fix is to manually correct the database to match the real file.

Steps to reproduce:
1. Create a VM with two or more disks on KVM.
2. Take a VM snapshot, then delete it while the VM has enough disk activity that the merge takes a while (or induce a timeout/communication failure partway through the multi-disk merge).
3. If one disk's merge completes on the host before another disk's merge fails/times out, the completed disk's volumes.path is left stale.
4. Attempt to start the VM. It fails looking for the old file.

Environment where this was observed: KVM, disk-only VM snapshots, VM with 2 disks (ROOT + DATA), primary storage on NFS.

Bắt đầu bằng cách lần theo đường dẫn xóa snapshot của KVM đối với các thao tác hợp nhất nhiều ổ đĩa và cách kết quả tổng hợp của nó cập nhật các đường dẫn volume; issue không cung cấp tên tệp hoặc tên kiểm thử. Tái hiện lỗi hợp nhất một phần, sau đó xác minh rằng các ổ đĩa đã hoàn tất vẫn giữ các đường dẫn cơ sở dữ liệu hợp lệ và VM có thể khởi động mà không cần sửa cơ sở dữ liệu thủ công.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.