Initial workflow client

[cretz]

What was changed

• Start workflow and get workflow result
• Workflow attributes
• Tests and scaffolding for the above
• EDIT: added all the rest of the client features, this is now a full-fledged SDK client

Note, this does not yet include all tests or all features. I am trying to get this in front of people early. I may continue to work on parts for this PR while it remains unapproved.

EDIT: This thing is full featured and ready to go.

[Sushisource]

Looking pretty good! Nothing blocking

[Sushisource]

I think the downcast could be fairly easily avoided by changing the various call methods/macros to return enum errors (use thiserror or w/e) rather than anyhow errors. They could even be tonic | other. Makes this match a bit cleaner and the code a bit more maintainable.

[cretz]

While it does make the match a bit cleaner, that my macros can return any error like inability to decode protos does make that code cleaner (though yes I could have a NotTonic(anyhow::Error)).

[Sushisource]

The macros should end up with the ability to work the same if you use the auto-From implementations generated by thiserror

[Sushisource]

It's a little sad that we reimplement pagination in every SDK. This could all be encapsulated in Core if we want (the code is there already), but I suppose we lose out on some low level interception (which I doubt anyone cares much about).

WDYT?

[cretz]

Usually I would concur, however I am about to write the history event async iterator which needs to control paging anyways so there'd be no value here. I wrote the interceptor and single-page fetching the way I did here with the expectation of reuse.

[Sushisource]

Why copied rather than re-used?

[cretz]

I don't want to add a dependency on the .NET gRPC library just for this

[Sushisource]

Worth explicitly distinguishing the difference between this and WorkflowQueryFailedException in the docstring I think

[cretz]

Will do! Also noticed a typo here that may help explain the difference too

Suggested change

	/// Thrown when a query is rejected by the worker due to bad workflow status.
	/// Thrown when a query is rejected by the server due to bad workflow status.

[Sushisource]

Seems like that's what it's there for

[cretz]

Kinda, but it's not "AggregateMessageException", it has separate exceptions carrying their own stack traces, causes, etc. But I agree, probably good enough, and bonus is the outputters know how to format this one well.

[jakejscott]

@cretz Not sure if you want to add another dependency, but Fluent Assertions library is alot nicer to use and gives better output when assertions fail.

It has a helpers that let you test a date is CloseTo some time and you pass it a TimeSpan of how close
https://fluentassertions.com/datetimespans/

The object graph comparision also comes in handy
https://fluentassertions.com/objectgraphs/

Also useful is the ability to async retry something and still use assertions in the body (which gives nice errors when it fails)...

Func<Task> asyncRetry = async () =>
{
    var describeExecutionResponse = await _stepFunctions.DescribeExecutionAsync(new DescribeExecutionRequest
    {
        ExecutionArn = executionArn
    });
    describeExecutionResponse.Should().NotBeNull();
    describeExecutionResponse.Status.Should().Be(ExecutionStatus.SUCCEEDED);
};
await asyncRetry.Should().NotThrowAfterAsync(waitTime: 60.Seconds(), pollInterval: 2.Seconds());

[cretz]

As the tests grow I very well may add that dependency or other test helpers (I don't mind adding dependencies to our test project). I haven't needed too much yet (and I have started an AssertMore package at the root of the project for a couple of them).

[cretz]

This PR has had as much review as it's going to receive I'm afraid. Merging.