avoid disk lun collision issue in edge case

[andyzhangx]

What happened:
in edge case, e.g. after etcd restore, the <disk1, LUN0> mapping already exists while actually disk1 is not attached to the node, and if another pod mounted with disk2 is scheduled to the node, it would occupy the LUN0, then both pods would consume disk1 in LUN0.

CSI driver could avoid such issue in disk attachment when disk2 is being attached to the node, the CSI driver controller could check the volumeattachments whether LUN0 is used or not by k8s controller, if it's already allocated logically, then the controller should allocate other empty LUN num.

• below is an example of volumeattachment, it has <disk1, LUN0> tied with a node name.

# k get volumeattachments -o yaml
apiVersion: v1
items:
- apiVersion: storage.k8s.io/v1
  kind: VolumeAttachment
  metadata:
    annotations:
      csi.alpha.kubernetes.io/node-id: aks-latest-31072707-vmss000000
    creationTimestamp: "2023-09-28T15:16:53Z"
    finalizers:
    - external-attacher/disk-csi-azure-com
    name: csi-641c6a1cf0ebd060dc679408fdd91916e87b3a7d43930373104b765f4adb8307
    resourceVersion: "77173779"
    uid: 83dc7070-ff20-49d9-986f-fc0d0c0d3e27
  spec:
    attacher: disk.csi.azure.com
    nodeName: aks-latest-31072707-vmss000000
    source:
      persistentVolumeName: pvc-7f99bade-becd-43a3-ba3f-dd2fddae9363
  status:
    attached: true
    attachmentMetadata:
      LUN: "0"

What you expected to happen:

How to reproduce it:

Anything else we need to know?:

Environment:

• CSI Driver version:
• Kubernetes version (use kubectl version):
• OS (e.g. from /etc/os-release):
• Kernel (e.g. uname -a):
• Install tools:
• Others: