Organize dashboard config to use strongly typed options, support primary/secondary API keys and rotation

[JamesNK]

Fixes #2996

• Change dashboard config to be loaded via options
  • Use options validation
  • Use options post config to apply shortcut config over the top of structured config, e.g. DOTNET_DASHBOARD_OTLP_ENDPOINT_URL is set to Dashboard:Otlp:EndpointUrl.
• Change OLTP API key auth to have primary and secondary keys
• Change OTLP API key auth to use IOptionsMonitor<T> to get latest keys after config changes
• Add DOTNET_DASHBOARD_CONFIG_FILE_PATH which configs a location to load JSON from a file. This can be used in cloud hosting scenarios to point at a mounted volume. Changes to the file can be applied to dashboard without restarting the app (for API key rotation without process restart)
• Tests

TODO:

• Resource service endpoint URL doesn't use new config yet
• Update dashboard readme
• Remove old code

Microsoft Reviewers: Open in CodeFlow

[JamesNK]

Review please 🙏

[JamesNK]

@drewnoakes I changed StoreName and Location just properties on the cert options.

Couple of reasons:

• This matches Kestrel endpoint config for HTTPS.
• Having store name and location in a nested KeyStore section seems odd when the subject isn't. And FilePath/Password isn't nested under a file section. Simpler to just have a flat list of properties.

[davidfowl]

@eerhardt we should use the config binder source gen and config schema generator, right?

[davidfowl]

Not important for this PR but it would look nicer if these were hidden in a helper extension method. Sorta like AddCertifcate is 😄

[davidfowl]

Why doesn't this come from options? It's because we're binding this type directly...

[JamesNK]

@drewnoakes ?

I think it's used as a simple way to set TLS config in tests without having to explicitly add more config.

[davidfowl]

I think we should own all of the options types and copy settings over explicitly. Less fragile. Can be follow up.

[JamesNK]

What do you think about continuing to do this, but not advertising it in docs? In other words, it's an internal implementaiton detail. A private API.

Then we add new options if people ask for them.

[davidfowl]

Can we preserve the schema?

[JamesNK]

I don't understand. What do you mean?

[davidfowl]

You said don't document it, I assume that to mean, we don't document it because we might change it later so it would be a breaking change if we do.

I'm asking if we know what the existing schema is, and can we preserve it to avoid breaking people.

[JamesNK]

It's the public getters and setters on https://learn.microsoft.com/en-us/dotnet/api/system.net.security.sslclientauthenticationoptions?view=net-8.0

[davidfowl]

I'm worried about this type adding something then suddenly config binding breaks. Or we switch to the source generator then it breaks.

[JamesNK]

It's not public API so we can switch the type behind the scenes.

[davidfowl]

Left feedback, but this LGTM

[JamesNK]

/backport to release/8.0-preview5

[github-actions]

Started backporting to release/8.0-preview5: https://github.com/dotnet/aspire/actions/runs/8437452822

[eerhardt]

@eerhardt we should use the config binder source gen

I would use the config binder source gen, yes. It's main benefit is trimming and AOT, but it also helps with startup perf because you don't need to use reflection to inspect the Options properties and set their values. The reflection based ConfigBinder is notoriously slow.

and config schema generator, right?

The config schema generator would have less value here because we don't ship a NuGet package for the Dashboard. Today, the only thing consuming these schemas is we put them in the NuGet packages, and when someone adds a PackageRef VS will pick it up and combine it in the appsettings.json schema. But here there is no flow like that. It would be useful for documentation purposes, or if we wanted to ship the config schema some other way.