fix race condition when delete azure disk right after that attach azure disk

[andyzhangx]

What type of PR is this?
/kind bug

What this PR does / why we need it:
fix race condition when attach/delete disk in same time
There is condition that attach and delete disk happens in same time, azure CRP don't check such race condition, this PR is to address such issue:
When there is disk attach/detach operation, it will first insert a record(key is diskURI) into diskAttachDetachMap and after operation completed, will remove that record. And in disk delete operation, will first check whether there is a record in the diskAttachDetachMap, if there is, then return error.

Which issue(s) this PR fixes:

Fixes #82714

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

fix race condition when attach/delete azure disk in same time

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

/kind bug
/assign @feiskyer @khenidak
/priority important-soon
/sig cloud-provider
/area provider/azure

/hold
hold a while for review and test

[andyzhangx]

cc @ritazh

[andyzhangx]

/test pull-kubernetes-e2e-aks-engine-azure

[andyzhangx]

/hold cancel
test pass on a local aks-engine cluster

below is the sample code showing how this works for sync.Map:

package main

import "fmt"
import "strings"
import "sync"

func main() {
	diskURI := "abc"
	var diskAttachDetachMap sync.Map
	diskAttachDetachMap.Store(strings.ToLower(diskURI), "")
	if _, ok := diskAttachDetachMap.Load(strings.ToLower(diskURI)); ok {
		fmt.Printf("1: failed to delete disk(%s) since it's in attaching or detaching state\n", diskURI)
	}
	diskAttachDetachMap.Delete(strings.ToLower(diskURI))
	if _, ok := diskAttachDetachMap.Load(strings.ToLower(diskURI)); ok {
		fmt.Printf("2: failed to delete disk(%s) since it's in attaching or detaching state\n", diskURI)
	}
}

expected output:
1: failed to delete disk(abc) since it's in attaching or detaching state

[andyzhangx]

/test pull-kubernetes-e2e-aks-engine-azure

[khenidak]

/hold until we understand more about the race condition.

[khenidak]

/unhold Let us have this as a stop gap for now.

[feiskyer]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: andyzhangx, feiskyer

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• staging/src/k8s.io/legacy-cloud-providers/azure/OWNERS [andyzhangx,feiskyer]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[andyzhangx]

BTW, there is another ToBeDetached flag issue, would be addressed by #84958, while that issue only happens from k8s 1.16.x

[andyzhangx]

/hold cancel

[andyzhangx]

/test pull-kubernetes-e2e-aks-engine-azure

[fejta-bot]

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to fejta).

Review the full test history for this PR.

Silence the bot with an /lgtm cancel or /hold comment for consistent failures.

[k8s-ci-robot]

@andyzhangx: The following test failed, say /retest to rerun them all:

Test name	Commit	Details	Rerun command
pull-kubernetes-e2e-aks-engine-azure	b6afc86	link	/test pull-kubernetes-e2e-aks-engine-azure

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.