Adding instance-based CreateInvokableHttpClient

[WhitWaldo]

Description

After installing the Dapr.Client NuGet package, there exists a method on a DaprClient called CreateInvokeHttpClient which accepts an appId, a daprEndpoint and a daprApiToken argument and produces an HttpClient that can be used to send well-formed HTTP requests to other applications accessible by Dapr.

After installing the Dapr.Client.AspNetCore package, developer get some extensions that simplify the registration of a DaprClient so it can be injected into downstream classes. This is great because especially if the developer is using a non-standard HTTP endpoint or is utilizing the Dapr API token, either can be retrieved in one place, registered in the Dapr client and later uses of the client can just be invoked - no need to keep retrieving those for new invocations.

I'd like to marry the two ideas - because CreateInvokeHttpClient is a static method on a DaprClient, it doesn't contain any of the properties set on a DI-registered DaprClient, so each invocation requires that I retrieve the daprApiToken and daprEndpoint values all over again, which simply doesn't make sense as I've already done it once at registration for all other instance-based operations.

This PR does just that - it takes the implementation of the static method and puts it into the DaprClient instance, pulling from the existing apiTokenHeader on the instance to populate the daprApiToken, pulling the endpoint from the instance's httpEndpoint value and accepting only an appId argument so as to specify the ID of the Dapr app to connect to and place in the resulting URI.

This way, a developer can register an instance of a DaprClient using a configured Dapr API token and non-standard HTTP endpoint once, and build an HttpClient from that instance that is already configured with these values when they want to invoke other Dapr endpoints without using the service invocation methods (enabling with the instance what they can already do with the static approach, minus the configured values).

Issue reference

We strive to have all PR being opened based on an issue, where the problem or feature have been discussed prior to implementation.

Please reference the issue this PR will close:

Checklist

Please make sure you've completed the relevant tasks for this PR, out of the following list:

• Code compiles correctly
• Created/updated tests
• [N/A] Extended the documentation

[philliphoff]

Should work, but a question about parallel implementations.