Simplify registration of remote app urls about systemweb-adapters

[mjrousos]

I like that option. It's not that different from just setting those options in SystemWebAdapters options directly, but it seems good to have remote app stuff separated out to keep things clear. I'll update things to work this way.

[davidfowl]

Also RemoteApp and ApiKey exist on both session and auth, maybe those should be consolidated?

[twsouthwick]

I believe @mjrousos is handling that as part of his auth implementation.

[mjrousos]

Sort of. This is a tricky one because, on the one hand, it feels bad to set these same values multiple times but, on the other hand, it also feels weird to configure things like ApiKey and RemoteAppUrl in core SystemWebAdapter configuration when those values aren't actually needed there (they're only needed for additional optional features like session sharing or auth sharing).

The way I've handled this in the auth PR so far is that I still require both session and auth configuration to set RemoteAppUrl and ApiKey, but I have both options types derive from a common base type with these properties so users can at least have code that sets these properties shared between both auth and session configuration.

I'm still not entirely happy with the solution, though, and think I will change it to have these properties set in SystemWebAdapter options even though they aren't used there. That's still not ideal but will be more readable.

Here's what using the approach in my auth PR currently looks like:

builder.Services.AddSystemWebAdapters()
    .AddJsonSessionSerializer(options => RegisterSessionKeys(options))
    .AddRemoteAppSession(ConfigureRemoteServiceOptions)
    .AddRemoteAppAuthentication(o => ConfigureRemoteServiceOptions(o.RemoteServiceOptions));

void ConfigureRemoteServiceOptions(RemoteServiceOptions options)
{
    options.RemoteAppUrl = new(builder.Configuration["ReverseProxy:Clusters:fallbackCluster:Destinations:fallbackApp:Address"]);
    options.ApiKey = "strong-api-key";
}

If we set things in SystemWebAdapters instead, it would look like this:

builder.Services.AddSystemWebAdapters(options =>
    {
        options.RemoteApp = new(builder.Configuration["ReverseProxy:Clusters:fallbackCluster:Destinations:fallbackApp:Address"]);
        options.ApiKey = "strong-api-key";
    })
    .AddJsonSessionSerializer(options => RegisterSessionKeys(options))
    .AddRemoteAppSession()
    .AddRemoteAppAuthentication();

[twsouthwick]

What about keeping it separate, but as a general remote app:

builder.Services.AddSystemWebAdapters(options =>
    {
    })
    .AddJsonSessionSerializer(options => RegisterSessionKeys(options))
    .AddRemoteApp(options =>
   {
        options.RemoteAppUrl = new(builder.Configuration["ReverseProxy:Clusters:fallbackCluster:Destinations:fallbackApp:Address"]);
        options.ApiKey = "strong-api-key";
   })
    .AddRemoteAppSession()
    .AddRemoteAppAuthentication();

And that would get plumbed through as an IOptions<RemoteAppOptions>:

public class RemoteAppOptions
{
  public Uri RemoteAppUrl { get; set; }
  public string ApiKey { get; set; }
}

We could potentially use named options to disambiguate if people want multiple, but I don't see that as a required scenario at the moment.