Added .NET client for new Dapr Jobs API support

[WhitWaldo]

Description

Added a Dapr Jobs client for the new Jobs API

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: #1321

Checklist

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

• Code compiles correctly
• Created/updated tests
• Extended the documentation

This isn't yet ready to be merged as I need to figure out how the sidecar signals job triggers back to the app.

[WhitWaldo]

/assign

[WhitWaldo]

What are you thoughts on dropping the serialization altogether here and just accepting a byte[] for the job payload? It puts the responsibility back on the developer to handle serialization however they want and means that we avoid the inevitable bug report of someone experiencing a runtime error because they've specified a different type to deserialize fom than they used whenever they created the job. By instead only accepting a byte[], they can use whatever serialization they desire on their side and gets the SDK out of having to support pluggable serialization.

@WhitWaldo We could take the .NET runtime approach and have the client offer a "plain" method that accepts the raw input (probably better to be ReadOnlyMemory<byte> rather than byte[]) and then offer extension methods that wrap the method with JSON-specific flavors (see HttpClient.PostAsync() and HttpClientJsonExtensions.PostAsJsonAsync<TValue>()). Those extension methods could have an additional overload that accepts, for example, a JsonSerializerOptions instance to configure things, which then offers very similar behavior to today's Dapr client class but without embedding all of the serialization logic in the "main" methods. While we still technically implement the serialization, it's more directly configurable by the user.

@philliphoff In the latest batch of commits, I added a collection of extension methods that'll support JSON and string serialization (with a JsonSerializationOptions passed in as an optional argument) and deserialization along with unit tests for the latter set.

As I discovered after a few failing unit tests, Moq doesn't work with static methods, which makes this project rather difficult to get full coverage on. Is there any interest at some point in seeing if there's a commercial mocking framework that would grant a license for this open-source project (e.g. Telerik's JustMock)? I've got to imagine there are a great many opportunities for richer coverage we just can't test with open-source mocking tooling.

Finally, I added a change to the generic Dapr client builder that took a dependency on Microsoft.Extensions.Http so we could source the HttpClient from its IHttpClientFactory.CreateClient method instead of creating one every time the builder is used and it'd be registered in DI alongside anything else. Unfortunately, this package takes a hard dependency on the 8.0.* logging which broke Dapr.Extensions.Configuration because of its chain of references and its existing reference to 3.1.2 for Microsoft.Extensions.Configuration. Updating to 8.0.* on the configuration project introduces a nullable incompatibility minefield, so I've instead I've fixed it for now by reverting the Microsoft.Extensions.Http to 3.1.32 (and upgrading the configuration project to the same). All that to say that when we drop .NET 6, it'd be a great time to both review #1004 and keep working through #1316 because with package updates, we're likely going to introduce more nullability work.

[WhitWaldo]

Unclear why the build is failing on CI/CD - it's building all the way through locally.

[WhitWaldo]

@philliphoff Closing this PR in favor of #1331 now that all the unit tests are passing. Did a squash merge per your suggestion to fix the DCO error.