[release/11.0] Update OpenTelemetry to 1.18.0

[nagilson]

Backport of #1802 to release/11.0. This fixes the source-only prebuilt failure in dotnet/dotnet#9582.

Why this branch

dotnet/sdk#56274 moved the SDK's release/11.0.1xx to OpenTelemetry 1.18.0. Source-only builds of dotnet/dotnet#9582 now fail with six prebuilts:

• OpenTelemetry, OpenTelemetry.Api, OpenTelemetry.Api.ProviderBuilderExtensions, OpenTelemetry.Exporter.InMemory, OpenTelemetry.Exporter.OpenTelemetryProtocol 1.18.0
• Microsoft.Extensions.Configuration.EnvironmentVariables 10.0.0

The VMR's release/11.0.1xx and release/11.0.1xx-rc2 branches both pin src/source-build-assets to the release/11.0 HEAD (71716795). SBA has no release/11.0.1xx-rc2 branch. A change only on main would not reach #9582.

Changes

This is a clean cherry-pick of b4d17ed from #1802. It follows the README section Updating an External Component to a Newer Version:

• opentelemetry-dotnet submodule moves to core-1.18.0 (9db92a4e). SourceRevisionId, FileVersionRevision (2160) and OpenTelemetryDotNetReleaseVersion are updated to match.
• Patch 0001 is refreshed. Patch 0002 (tolerate missing origin remote) is dropped because upstream now includes IgnoreStandardErrorWarningFormat.
• /p:IsAotCompatible=false is added so the build does not restore Microsoft.NET.ILLink.Tasks, which is not available at this bootstrap layer.
• A Microsoft.Extensions.Configuration.EnvironmentVariables 10.0.0 reference package is added. OpenTelemetry 1.18.0 depends on [10.0.0,).

The contrib packages are unchanged: Instrumentation.Http 1.16.0, Runtime 1.15.1 and PersistentStorage 1.1.0. SDK release/11.0.1xx bumps OpenTelemetryPersistentStoragePackageVersion to 1.1.1, but in source-only builds OpenTelemetry.PersistentStorage.FileSystem is only a PackageVersion entry with no PackageReference. It came in transitively through Azure.Monitor.OpenTelemetry.Exporter, which is excluded when DotNetBuildSourceOnly=true. It also did not appear in the prebuilt report.

Validation (Linux, Ubuntu 26.04)

• ./build.sh -sb succeeds.
• The expected packages are produced: the five OpenTelemetry 1.18.0 packages plus Microsoft.Extensions.Configuration.EnvironmentVariables.10.0.0.nupkg.
• ExternalPackageTests: 5/5 pass, including ReleaseVersionMatchesPackageOutput.

Expected source-build-assets-unified-build result

azure-pipelines/builds/vmr-build-pr.yml inserts this PR into VMR main, which still pins OpenTelemetry 1.16.0. That produces the same version skew seen on #1802: SDK layout DLLs are 1.16.0, while the collected PDBs are 1.18.0, so SymbolsTests.VerifySdkSymbols fails. #1742 went through the same sequence: it merged while this check was red, and dotnet/sdk#55216 then aligned the SDK pins. Here the SDK side is already on 1.18.0 in dotnet/dotnet#9582. This change and dotnet/dotnet#9582 need to meet in VMR release/11.0.1xx.

Note

This PR description was drafted with AI assistance (GitHub Copilot).

[nagilson]

/azp run source-build-assets-unified-build

Note

Comment posted with AI assistance (GitHub Copilot), per the README step to trigger a full VMR source build.

[azure-pipelines]

No pipelines are associated with this pull request.

[mthalman]

This is just going to fail in the dependency flow to the VMR because the SDK's OTel reference will still be 1.16.0. So it'll just cause prebuilts there. When making dependency version updates, they should be combined into one PR. So apply these changes to dotnet/dotnet#9582.

[nagilson]

I didn't recognize there was a opentelemetry-dotnet-contribsubmodule.

I think the fact that we updated OpenTelemetry to 1.18.0 but not OpenTelemetryDotNetContribPersistentStorageFileSystemReleaseVersion from 1.0.0 to 1.1.1 will cause a Source-Build SDK Baseline Diff baseline failure becauseOpenTelemetry.PersistentStorage.*.dll wont be in the source built SDK but the microsoft built SDK will have 1.1.1.