Validate that timeout is positive in WaitForOrchestrationAsync, and enable nullable checks

[davidmrdavid]

This PR validates that the timeout in WaitForOrchestrationAsync is positive. Otherwise, we risk accidentally returning null without doing any meaningful work.

This PR also enables nullable analysis for part of the AzureStorageOrchestrationService file

I encountered this in the process of repro'ing this issue: microsoft/durabletask-dotnet#143

[jviau]

Should we accept negative values? There seems to be a precedence that negative implies infinite for timeouts. Especially since Timeout.InfiniteTimeSpan is negative.

[davidmrdavid]

Maybe, I think it's up for debate, and I no strong feelings on this. I simply noticed that the code today assumes the timeout will be positive, and so I made that assumption explicit by validating the input.

Using a combination of Datetime.now and the provided timespan, we can modify the currrent implementation to work with infinite timespans as well.

Would you prefer if we accepted negative timespans? I see no issue with that

[jviau]

I think it would be a better experience to accept negative as an infinite timeout.

[cgillum]

I'd say let's be specific and allow for Timeout.InfiniteTimeSpan to mean infinite, whereas we throw for any other negative value. I believe this is mostly consistent with other .NET APIs and helps us differentiate an explicit desire for infinite vs. an accidental negative value provided by the user.

So here, I think we'd say if (timeout < TimeSpan.Zero && timeout != Timeout.InfiniteTimeSpan) and below, we change the while loop condition to be while (!cancellationToken.IsCancellationRequested) (removing the timeout check).

[davidmrdavid]

I like the compromise of explicitly checking for Timeout.InfiniteTimeSpan, and erroring out in other negative TimeSpan cases. My latest commit tries to do just that.

My if statement is as you suggested, @cgillum. However, the while loop does preserve the timeout check because I think we need it for the "happy case" where the timeout is positive. I suppose I could also move it to an if-statement check inside the while loop though.

[cgillum]

Happy to see you decided to support Timeout.InfiniteTimeSpan. :)

Added some non-blocking suggestions. I realize the one regarding TimeSpan.Zero would require some refactoring for a "perfect" implementation, so I'm fine if you want to skip that.

[davidmrdavid]

@cgillum: let's try to get this right all the way. Does this latest commit look good to you?

[cgillum]

LGTM!