Enhance workflow management with runtime

[MyMirelHub]

Adds gRPC sidecar calls from dontet for new workflow commands

[atrauzzi]

I wonder if there's a way to pull these off of DaprClient instead.

[MyMirelHub]

Doesn't look like it - perhaps it should be a feature but we can make it easier by piggybacking from the gRPC channel services.AddDaprWorkflow() already uses and DI TaskHubSidecarService.TaskHubSidecarServiceClient

[MyMirelHub]

@WhitWaldo are we wrapping the RPC calls in the SDK?

[msfussell]

@WhitWaldo - Is this valid still? Do we want to recommend this way?
@MyMirelHub - THis is draft. Were you waiting on Whit?

[WhitWaldo]

@WhitWaldo - Is this valid still? Do we want to recommend this way? @MyMirelHub - THis is draft. Were you waiting on Whit?

I believe this implementation was started using the 1.16 version of the Dapr .NET SDK given that step 1 suggests that one creates a gRPC client and references the Dapr.DurableTask.Protobuf namespace. This namespace no longer exists as of 1.17 following the rewrite to remove all dependencies on DurableTask.

@MyMirelHub Typically, we don't advise people to go make a gRPC client and call into Dapr directly - that's the whole point of the SDKs to abstract that. I would wholeheartedly be willing to discuss adding another SDK package, e.g. Dapr.Workflow.Management or the like that embodies what it is you're expressing there, but SDK workaround feels like a bad user experience that really doesn't belong in the official documentation.

[msfussell]

@MyMirelHub - I suggest closing this PR.

[MyMirelHub]

Closing in favour of discussing sdk management for workflow commands - a draft here dapr/dotnet-sdk#1738