`HttpClient` quality of life

[atrauzzi]

As per some discussions on discord, I'm opening up this issue to track potential priorities for making life with HttpClient more enjoyable!

I've been fumbling around with trying to get the kiota library working with HttpClient instances provided by dapr. I've observed one pain point that likely could be alleviated with help from either dotnet itself, or the kiota library. And then one item which dapr will likely fix in 1.16:

1. It's not clear to me how to best obtain the HttpClient that I end up providing to kiota
2. It looks like improvements to getting preconfigured HttpClient instances didn't make it into the 1.15 version of the dapr sdk. 😅

Item 1 obviously doesn't directly impact the dapr library, although I think it's a kind of scenario that it should be prepared to offer people boilerplate guidance on. It will inevitably come with the territory of offering to produce HttpClient instances.

Item 2 I suspect is already in-hand (😜 @WhitWaldo)

---

For the 2nd half of this discussion, I'll just share where I'm at with this little experiment to help inspire any potential quality of life improvements dapr can offer from its end.

In its most naive form, this is what I've made in my Program.cs:

builder.Services.AddSingleton<IAuthenticationProvider, AnonymousAuthenticationProvider>(
    (_) => new());

builder.Services.AddTransient<MyGeneratedClient>((serviceProvider) =>
{
    var authenticationProvider = serviceProvider.GetRequiredService<IAuthenticationProvider>();
    var daprClient = serviceProvider.GetRequiredService<DaprClient>();

    // note: As of and prior to `1.15`, this _could_ cause port exhaustion.
    var httpClient = daprClient.CreateInvokableHttpClient();

    // note: kiota allows you to provide "adapters" to their generated clients. This is where I think there can be synergies between dapr and kiota!
    return new MyGeneratedClient(new HttpClientRequestAdapter(
        authenticationProvider,
        httpClient: httpClient
    ));
});

There is some documentation from the kiota project on how to configure dependency injection, although I'm questioning whether it's applicable to my scenario. Particularly because I'll be working with an HttpClient already from dapr.

If I remember anything else, I'll edit or comment as appropriate.

[WhitWaldo]

I'm initially thinking that this can be addressed in 1.16 with the shift to the Dapr.Invocation package. I'll figure out what exactly it is that Kiota needs in terms of DI registration and see about augmenting the existing HttpClient registration to expose methods allowing these configurations, then look at building out another small package for Dapr.Invocation.Kiota that provides an extension method to utilize those endpoints and handle registration.

Ideally, in the end, with both the Dapr.Invocation and Dapr.Invocation.Kiota packages installed, registration might then look similar to:

builder.Services.AddDaprInvocation().WithKiota();

[WhitWaldo]

As part of this work effort, make sure the HttpClient is honoring logging levels specific in the configuration, if any as this appears to be getting ignored (per @olitomlinson ) between 1.14 and 1.15.