Support for azure-syncoperation in azure_mgmt_compute::virtual_machines::Client to Confirm VM Creation Status

[pichuang]

After testing, it was found that when using azure_mgmt_compute::virtual_machines::Client with 0.20.0 / 0.19.0, it returns provisioning_state: Succeeded in a very short time. https://github.com/pichuang/azure-rust-lab/blob/main/lab-azure-create-1-vm/output/PUT-1-VM.txt#L373-L374

    let _vms = client
        .virtual_machines_client()
        .create_or_update(
            resource_group,
            vm_name,
            parameters_pinhuang,
            subscription_id,
        )
        .await?;

Source code: https://github.com/pichuang/azure-rust-lab/blob/main/lab-azure-create-1-vm/src/main.rs

However, as I understand from Track asynchronous Azure operations, to confirm that the VM creation is completed, it requires a Succeeded response from azure-syncoperation. But I see that azure_mgmt_compute::virtual_machines::Client does not provide a way to get the content of the HTTP Response, which prevents user from being able to process the headers additionally.

Because we have users who will instantly launch more than 1500 VMs, I want them to use azure-syncoperation to confirm the creation status of each VM. This way, if any VM fails to be created or takes too long to create, we can handle it early.

or any better suggestions?

[pichuang]

In addition, we also found that when using this SDK to create a VM, it simultaneously generates 2 identical PUT Requests. If a large number of requests to create VMs are made in a short period of time, in addition to encountering ARM / NRP / CRP / SRP throttles requests, there is a considerable chance that it will cause anomalies in the Azure Backend Infra.

https://github.com/pichuang/azure-rust-lab/blob/main/lab-azure-create-1-vm/output/PUT-1-VM.txt#L305
https://github.com/pichuang/azure-rust-lab/blob/main/lab-azure-create-1-vm/output/PUT-1-VM.txt#L366

[pichuang]

After testing, I can now get the header correctly

    let _vm = client
        .virtual_machines_client()
        .create_or_update(
            resource_group,
            vm_name,
            parameters_pinhuang,
            subscription_id,
        )
        .send();
        // Avoid twice HTTP PUT, and get the Header from respone
        //.await?; 

    // Get the raw response and print the header AZURE_ASYNCOPERATION
    let binding = _vm.await.expect("SOME THING WRONG");
    let raw_response = binding.as_raw_response();

    if let azure_asyncoperation = raw_response.headers().get_str(&azure_core::headers::AZURE_ASYNCOPERATION) {
        println!("{:?}", azure_asyncoperation);
    } else {
        println!("No header");
    }

[andlr]

Looks like something I've reported here #1525
I've described only snapshots there, but I've had the same problem for disks and VMs as well.
As a workaround, I've created a fork and manually replaced IntoFuture implementations to the correct ones in the generated code (services/mgmt/compute/src/package_2023_10_02/mod.rs)