Fix issue where AppInsights SDK doesn't load/configure correctly due to keyed services being registered in DI

[martinothamar]

Description

A bug report came in, where logs/telemetry wasn't being shipped to AppInsights.
Upon inspecting the IServiceCollection registrations after calling AddApplicationInsightsTelemetry, we discovered that everything until (and including) these lines of registrations succeeded:
https://github.com/microsoft/ApplicationInsights-dotnet/blob/4626e3632323b741a2bd56d3d529c283cf7626c9/NETCORE/src/Microsoft.ApplicationInsights.AspNetCore/Extensions/ApplicationInsightsExtensions.cs#L134

However the TelemetryClient itself was never registered in DI. In the code linked above, if there is an exception, it is (relatively silently) swallowed and registered on the event source for AppInsights.

We traced the event source in a local test app:

dotnet trace collect --providers Microsoft-ApplicationInsights-AspNetCore -- ./bin/Debug/net8.0/Altinn.App

Which could be loaded into PerfView

We see this error:

HasStack="True" ThreadID="2,558,902" ProcessorNumber="0" errorMessage="System.InvalidOperationException: This service descriptor is keyed. Your service provider may not support keyed services. at Microsoft.Extensions.DependencyInjection.ServiceDescriptor.ThrowKeyedDescriptor() 
at Microsoft.Extensions.DependencyInjection.ServiceDescriptor.get_ImplementationFactory() 
at Microsoft.Extensions.DependencyInjection.ApplicationInsightsExtensions.<>c__28`2.<AddSingletonIfNotExists>b__28_0(ServiceDescriptor o) 
at System.Linq.Enumerable.Any[TSource](IEnumerable`1 source, Func`2 predicate) 
at Microsoft.Extensions.DependencyInjection.ApplicationInsightsExtensions.AddSingletonIfNotExists[TService,TImplementation](IServiceCollection services) 
at Microsoft.Extensions.DependencyInjection.ApplicationInsightsExtensions.AddCommonTelemetryModules(IServiceCollection services) at Microsoft.Extensions.DependencyInjection.ApplicationInsightsExtensions.AddApplicationInsightsTelemetry(IServiceCollection services)" appDomainName="Altinn.App" 

Which means that AppInsights thinks that our DI container (Scrutor) doesn't support keyed services. I think that's right? Since there is an open issue on that: khellang/Scrutor#209

This PR replaces keyed services by just injecting multiple services, and introducing a second marker interface to distinguish between them instead.

Other options:

• Use a different DI container (for example the built in one), which supports keyed services right now?
• ?

Related Issue(s)

• N/A

Verification

• Your code builds clean without any errors or warnings
• Manual testing done (required)
• Relevant automated test added (if you find this hard, leave it and we'll help out)
• All tests run green

Documentation

• User documentation is updated with a separate linked PR in altinn-studio-docs. (if applicable)

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[martinothamar]

We can probably also just register AppInsights earlier in the DI container, since the issue is provoked when AppInsights scans the registry.. https://github.com/microsoft/ApplicationInsights-dotnet/blob/4626e3632323b741a2bd56d3d529c283cf7626c9/NETCORE/src/Shared/Extensions/ApplicationInsightsExtensions.cs#L297
But that would feel less solid