Describe the bug

From [e2e] test result(https://ci.longhorn.io/job/public/job/master/job/sles/job/amd64/job/longhorn-tests-sles-amd64/47/testReport/junit/tests/test_cloning/test_cloning_with_detached_source_volume/), not happened on v1.2.3

If we clone PVC form detached volume, the cloned one will stuck at not ready for workload

To Reproduce

Steps to reproduce the behavior:

1. Create PVC

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: source-pvc
spec:
  storageClassName: longhorn
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

2. Wait for volume to be created and attach it to a node
3. Write some data to the mount path of the volume
4. Detach the volume and wait for the volume to be in detached state
5. Clone a volume by creating the PVC

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: cloned-pvc
spec:
  storageClassName: longhorn
  dataSource:
    name: source-pvc
    kind: PersistentVolumeClaim
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

6. Cloned PVC will stuck at not ready for workload

Expected behavior

Cloned PVC will ready for workload

Log or Support bundle

longhorn-support-bundle_f2c9c294-22d7-4a09-bd05-f89d5a1d7490_2022-03-03T08-32-30Z.zip

Environment

• Longhorn version: master-head 0303
• Installation method (e.g. Rancher Catalog App/Helm/Kubectl): kubectl
• Kubernetes distro (e.g. RKE/K3s/EKS/OpenShift) and version: K3s
  • Number of management node in the cluster: 1
  • Number of worker node in the cluster: 3
• Node config
  • OS type and version: suse-sles-15-sp3-v20210622-hvm-ssd-x86_64
• Underlying Infrastructure (e.g. on AWS/GCE, EKS/GKE, VMWare/KVM, Baremetal): AWS
• Number of Longhorn volumes in the cluster: 1

Additional context

Not happen when source volume in attached status