[receiver/azuremonitorreceiver] parallelize calls by subscriptions in Batch API mode

[celian-garcia]

Description

This PR revives the previously non-functional #40344, aiming to enhance performance by running metrics collection across Azure subscriptions in parallel. This significantly reduces latency when dealing with multiple subscriptions.

Compared to the original PR, this version addresses a critical concurrency issue:
fatal error: concurrent map read and map write
Reference: https://victoriametrics.com/blog/go-sync-map/

To resolve this, I evaluated multiple approaches and found that using the concurrent-map library yielded the best results. Details of the evaluation and benchmarks are documented in concurrency_bench_report.md.

Link to tracking issue

Fixes #39417

Testing

During testing, a race condition was discovered in the Azure SDK related to the fallback behavior of the Cloud option in the NewClient function:

// NewClient creates a client that accesses Azure Monitor metrics data.
// Client should be used for performing metrics queries on multiple monitored resources in the same region.
// A credential with authorization at the subscription level is required when using this client.
//
// endpoint - The regional endpoint to use, for example https://eastus.metrics.monitor.azure.com.
// The region should match the region of the requested resources. For global resources, the region should be 'global'.
func NewClient(endpoint string, credential azcore.TokenCredential, options *ClientOptions) (*Client, error) {
	if options == nil {
		options = &ClientOptions{}
	}
	if reflect.ValueOf(options.Cloud).IsZero() {
		options.Cloud = cloud.AzurePublic // <-- HERE
	}
	c, ok := options.Cloud.Services[ServiceName]
	if !ok || c.Audience == "" {
		return nil, errors.New("provided Cloud field is missing Azure Monitor Metrics configuration")
	}

To prevent this, our implementation explicitly sets the Cloud option in all cases, ensuring deterministic behavior and avoiding the race.

Documentation

A new markdown file (concurrency_bench_report.md) has been added to document:

• The rationale behind choosing concurrent-map
• Benchmark results comparing different implementations
• Notes for future contributors who may want to explore alternative concurrency strategies

[celian-garcia]

Sorry for this failing test. It's flaky and I thought I fixed it. I will have to check twice.
=> EDIT: fixed. See PR description

[atoulme]

Please address the conflict.

[celian-garcia]

@atoulme, conflicts resolved 🙂