{AKS} Fix missing wait on LRO pollers in azuremonitormetrics helpers

[FumingZhang]

Related command
az aks create --sku automatic, az aks addon/Azure Monitor metrics enablement commands (any command path that calls ensure_azure_monitor_profile_prerequisites, e.g. create_dce/create_dcr/create_dcra/addon_put/create_default_mac/link_grafana_instance).

Description
create_dce, create_dcr, create_dcra, addon_put, create_default_mac, and link_grafana_instance (in azure.cli.command_modules.acs.azuremonitormetrics) all call begin_create_or_update/begin_create_or_update_by_id but never call .result()/.wait() on the returned poller before returning.

Because the generic ResourceManagementClient used here polls via a background thread, the code proceeds as soon as the initial PUT is accepted instead of waiting for the resource to actually finish provisioning.

This is invisible in VCR-recorded tests (responses replay instantly, so the background poller thread finishes almost immediately), but is exposed in live tests: azure-cli-testsdk's tearDown() asserts that no thread named "LROPoller" is still alive (scenario_tests/base.py). A live az aks create --sku automatic run (which always provisions DCE/DCR/DCRA/Grafana-link resources for Azure Monitor metrics) can leave one of these pollers still polling in the background after the command returns, failing that assertion, and more generally means the CLI can return control to the caller before these dependent resources are actually ready.

Fix: capture the poller returned by each begin_create_or_update/begin_create_or_update_by_id call and call .result() on it before returning, so callers only get control back once the resource has actually finished provisioning. No public interface/behavior changes other than the command now waiting for these ARM operations to complete.

Testing Guide

az aks create -g <rg> -n <name> --sku automatic --enable-hosted-system \
  --workspace-resource-id <log-analytics-workspace-id>

Before the fix, a live test run of any @live_only() scenario that creates a --sku automatic cluster (which always enables Azure Monitor metrics and calls the affected helpers) could fail in tearDown() with:

AssertionError: You need to call 'result' or 'wait' on all LROPoller you have created

After the fix, this teardown assertion should no longer trigger from these code paths, since each begin_create_or_update[_by_id] call is now fully awaited via .result().

History Notes
[AKS] Fix missing wait on LRO pollers when provisioning Azure Monitor metrics artifacts (DCE/DCR/DCRA/Grafana link) for az aks create --sku automatic

---

This checklist is used to make sure that common guidelines for a pull request are followed.

• The PR title and description has followed the guideline in Submitting Pull Requests.

• I adhere to the Command Guidelines.

• I adhere to the Error Handling Guidelines.

[azure-client-tools-bot-prd]

Validation for Azure CLI Full Test Starting...

Thanks for your contribution!

[azure-client-tools-bot-prd]

Validation for Breaking Change Starting...

Thanks for your contribution!

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[yonzhan]

AKS