dotnetup: Use connection string rather than an ikey

[nagilson]

Instrumentation keys are an old mechanism which are replaced by connection strings.

https://learn.microsoft.com/en-us/azure/azure-monitor/app/connection-strings https://learn.microsoft.com/en-us/azure/azure-monitor/app/migrate-from-instrumentation-keys-to-connection-strings#whats-the-difference-between-global-and-regional-ingestion

Motivation

In #54733, I noted using curl that hitting the ingestion endpoint via the likely added 50-60ms on a median call (for me, not the median user). But after more testing, I found this actually shaves 198ms median off the time to POST telemetry which means more data will get through and it will take less time to flush.
(The curl demo did not actually test the e2e workflow of sending telemetry and using the connection string.)

Additionally, there is another win in that data will not be lost as it is with using an instrumentation key, see below.

Background

This documentation shown above outlines the following:

1. App Insights resources may be sharded regionally or ingested into one final bucket. If they are ingested into one bucket, there is only one ingestion endpoint. A global redirect may use different regional endpoints may exist to route an instrumentation key to the ingestion endpoint but the ingestion endpoint is not globally distributed.
2. Data sent via ikeys might be lost - this is what we have observed. Now, the docs don't give a reason but we can assume it's because the redirects may fail, or servers may be transient, etc.

Empirically:

I noticed that for one and done environments, hitting the end point that resolves from the instrumentation key using curl for the first time would often fail, returning the following: no data of the requested type response.

I attempted to hit various endpoints and observed that they all finally redirected to the same place. (and that we only have southcentralus as a viable endpoint)

Endpoints hit to redirect from the Ikey:
URL Result
https://dc.services.visualstudio.com/v2.1/track 307 to https://southcentralus-0.in.applicationinsights.azure.com/v2.1/track https://dc.applicationinsights.azure.com/v2.1/track same 307 target https://dc.applicationinsights.microsoft.com/v2.1/track same 307 target

(this comes from https://github.com/Azure/azure-sdk-for-net/blob/main/sdk/monitor/Azure.Monitor.OpenTelemetry.Exporter/src/Internals/ConnectionString/Constants.cs)

southcentralus as the only viable endpoint:
URL Result
southcentralus-0.in.applicationinsights.azure.com 200, itemsAccepted: 1 southcentralus.in.applicationinsights.azure.com 200, itemsAccepted: 1 centralus-2.in.applicationinsights.azure.com 400, Invalid instrumentation key westus2-0.in.applicationinsights.azure.com 400, Invalid instrumentation key japaneast-0.in.applicationinsights.azure.com 400, Invalid instrumentation key

Further evidence:

Aspire and other repos already do this, https://github.com/microsoft/aspire/blob/bc1bd6f77a5e25bf61fd70f89faa47552d557f2f/src/Aspire.Cli/Telemetry/TelemetryManager.cs#L37 as does the OTEL's own exporter Doc: https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/exporter/azuremonitorexporter/AUTHENTICATION.md

I also asked the devdiv data team about this; although they were unsure they did provide the full connection key for me to use which I was able to test empirically with.

[Copilot]

Pull request overview

Updates dotnetup’s Application Insights configuration to use a full Application Insights connection string (including ingestion endpoint) instead of relying on an instrumentation-key-only value, aligning with current Azure Monitor guidance and avoiding extra redirect/latency on ingestion.

Changes:

• Replace the dotnetup telemetry constant from an ikey-only value to a full connection string including IngestionEndpoint, LiveEndpoint, and ApplicationId.

[dsplaisted]

FYI @baronfel