Possible race condition in az vm disk attach/detach

**Describe the bug**

I haven't verified this bug in action, but reading the code https://github.com/Azure/azure-cli/blob/dc7478e39ce88bd4329027bbbded282477c853e4/src/azure-cli/azure/cli/command_modules/vm/custom.py#L1702-L1739 it looks like it's possible for `az vm disk attach` / `az vm disk detach` to attach or detach more disks than requested, if it is being called concurrently targeting the same VM.

Consider this (poorly formatted) concurrency diagram with two `az vm attach`es:

```
Client 1 Client 2
==================== ====================
$ az vm attach DISKX
get vm info
disks: [] $ az vm attach DISKZ
add data disk DISKX get vm info
disks: [DISKX] disks: []
update vm with [DISKX] add data disk DISKZ
disks: [DISKZ]
update vm with [DISKZ]
```

Unless there's a resource version involved in the VM model retrieved from the API, my intuition says this could end up in a situation where the VM only has DISKZ attached when the intended result is that both DISKX and DISKZ get attached.

The same applies to `az vm detach`, where the CLI filters its local view of the data disk list to exclude the disk to be detached.

**To Reproduce**

As said above, I haven't reproduced this in action, but if it is a real bug, it could be reproed with two carefully timed `az vm attach`es.

**Expected behavior**

Disk attaches and detaches are atomic.

**Environment summary**

n/a

**Additional context**

I came across this when looking at how `az vm disk attach` was implemented, since to my surprise there isn't a direct attach/detach call for disks in https://docs.microsoft.com/en-us/rest/api/compute/disks ...