Dapr Workflow Overhaul

[WhitWaldo]

Description

This PR represents an effort to dramatically overhaul how the .NET implementation of Dapr Workflows is written.

This completely removes our dependency on the DurableTask libraries (including our fork of Dapr.DurableTask) and fundamentally alters how the underlying system works operationally to remove all the logic not directly used by the Dapr runtime, applies modern .NET architecture ideas and syntax (nullability support, DI, records) and most of all, seeks to avoid any breaking changes with the existing Dapr.Workflow public API.

This approach simplifies the gRPC client creation to eliminate several types of bugs seen in the development of 1.16 and to further improve reliability and performance of the client, especially during heavy load.

Updating the examples, the only change needed was that requests to get the workflow state return a nullable instance of WorkflowState, but I otherwise saw drop-in support.

Outside of just making it easier to develop and maintain the project, this implementation also fixes several issues raised by the broader community:

#1567 identified issues with Serilog registration because of the additional scope creation as part of the DI registration - because the underlying types are registered differently, the additional scope creation has been removed and this issue will be resolved.

#1537 and #1582 sought more customized workflow serialization support. I'll do you one better - this implementation completely abstracts all serialization into an IWorkflowSerializer and provides a default implementation using System.Text.Json. Via the DI registration methods, you can pass in your own JsonSerializationOptions or even implement your own concrete serializer (just needs to be able to serialize/deserialize to and from a string) to support MessagePack, BSON or whatever you want and it'll just work. Do use some caution here - changing any of these settings means that when a workflow is rehydrated, it may not deserialize properly and would throw instead of complete successfully. Further, if you're using multi-app run (not yet supported in .NET, but WIP), your other applications will need to similarly support the same serialization scheme - to my knowledge, all other Dapr SDKs support JSON exclusively, so be advised.

#1532 calls to making it easier to demonstrate testing workflows, so I've added several interfaces throughout that can be used to facilitate this.

I'm currently working to add support for task execution IDs per #1541, multi-app run per #1636 and a bunch of unit tests to validate it through.

No changes should be necessary to the documentation as it should be a drop-in replacement for the existing public API, even though the entire backing apparatus has changed.

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: #[issue number]

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