WaitForCompletionOrCreateCheckStatusResponseAsync has no way to restore default behavior

[ConnorMcMahon]

In versions 1.x of the extension, calling the Get Status API would return a 500 if the orchestration instance had failed. To follow better API design, in 2.x of the extension, we changed the default behavior to return a 200 while simply marking the status field as "Failed". On the actual HTTP API and the IDurableClient.CreateCheckStatusResponse API, we have an optional parameter returnInternalServerErrorOnFailure to restore the 1.x behavior.

As @dixonte pointed out, IDurableClient.WaitForCompletionOrCreateCheckStatusResponseAsync is missing this optional parameter, leaving no way to have it return an HTTP response payload with the correct query string parameter filled out.

[ConnorMcMahon]

I am hesitant for two reasons:

1. API bloat. Adding optional parameters adds both a maintainability burden as well as potentially confuses API consumers who don't need/want that functionality.
2. Adding optional parameters breaks peoples tests for Moq.

[dixonte]

If this feature is added -- and possibly regardless -- I would like to suggest that in the case where IDurableClient.WaitForCompletionOrCreateCheckStatusResponseAsync returns before creating the check status response, the response should follow the same format as the Get Status API. This would allow clients to reliably check the Status regardless of how quickly the orchestration completed.