Upgrade to micrometer-registry-azure-monitor to major applicationinsights-core version

[tunovic]

Please describe the feature request.
Currently last micrometer-registry-azure-monitor uses applicationinsights-core version 2.6.4 which has high security vulnerabilities CVE-2024-47072, CVE-2021-43859

Rationale
Simple version override is not possible as it jumps to major version upgrades that isn't backwards compatible.

It would be nice to upgrade this to next major version and make the implementation compatible.

[jewoodev]

This seems to hit the same migration constraint discussed in #3420 — flagging the prior context so triage doesn't have to re-derive it.

A version bump alone may address the vulnerable dependency version, but it would not be a safe registry fix. Starting with Application Insights Java 3.x, the applicationinsights-core JAR is documented as a no-op API artifact:

"There are typically no code changes when upgrading to 3.x. The 3.x SDK dependencies are no-op API versions of the 2.x SDK dependencies. However, when used with the 3.x Java agent, the 3.x Java agent provides the implementation for them."

Telemetry transport is implemented by the 3.x Java agent (-javaagent:applicationinsights-agent-3.x.jar). Without the agent attached, TelemetryClient.track(...) / client.flush() calls in AzureMonitorMeterRegistry compile and run but emit nothing. Bumping application-insights to 3.7.x in libs.versions.toml would silently break Azure Monitor publishing for users not running the agent (and would not serve GraalVM native-image users).

Paths the maintainers already weighed in #3420:

• Use micrometer-registry-otlp if Azure Monitor accepts OTLP metrics directly.
• Build a new registry on top of azure-monitor-opentelemetry-exporter, or directly on azure-core against the Azure Monitor ingestion API.
• Whether such a registry should live here or under the Azure org was left open.

The CVEs in 2.6.4 are real and reinforce that 2.x can't be carried indefinitely, but they don't change the technical constraint that 3.x provides no standalone transport for a metrics library — the API is preserved as an agent-backed no-op. The blocker here looks like a direction call (deprecate the module + point users to OTLP, vs. invest in a new registry), not a simple dependency upgrade.

[shakuzen]

Thanks for the summary of the history @jewoodev. I don't know if anything has substantially changed since the last time we looked into this and there is some path forward or not. If there is no path forward for micrometer-registry-azure-monitor, we should deprecate it to reflect the lack of support for compatible dependencies. Does anyone know if Azure now provides and OTLP endpoint that could be used with micrometer-registry-otlp?