Durable functions - 'Function chaining' scenario support

[daxian-dbw]

Purpose of the PR

The purpose is to seek feedback and also transfer my learnings to @tylerl0706
Not seeking to merge to /dev branch, as the durable function is not in scope for the private preview (maybe not even in the scope of the public preview).

But since I started the investigation, it's a better use of my time to finish it, to some extent, so that we don't lose the learnings and related knowledge.

Summary

This is the initial changes to support the "Function Chaining" pattern of the durable function.

The main work involved are from two aspects:

1. Figure out a mechanism for powershell worker to be able to stop in the middle of an execution, discard the current execution, and replay the execution when needed.
2. Figure out the out-of-proc execution protocol used by durable-js.

For (1), the solution is to take advantage of the async invocation APIs BeginInvoke, EndInvoke and Stop. An AutoResetEvent named actionEvent is added to PowerShellManager, which will be passed to Invoke-ActivityFunctionAsync along with the history events. Once PowerShellManager starts the execution of an orchestration function by BeginInvoke, it will get an AsyncResult object back, then it will wait on either actionEvent or asyncResult.AsyncWaitHandle to be set.

• If the former is set, that means the Invoke-ActivityFunctionAsync is requesting for scheduling a new activity, and PowerShellManager will stop the execution by calling Stop() and handle the requested actions.
• If the latter is set, that means the orchestration function has run to completion.

Inside the Invoke-ActivityFunction, based on the history events, if it needs to schedule an activity function, then it creates actions and attaches them to the context object; if the activity function already completes, then it's a replay, and it just writes the result to the pipeline.

For (2), I mimic the implementation of durable-js on how to handle messages related to durable function execution.

[daxian-dbw]

The CI failure was because I didn't update the test after changing the signature of an internal API. Will get that resolved soon.

[daxian-dbw]

The refactoring changes were merged in a separate PR, and the durable function implementation is rebased and cleaned up.

The pester tests failed in CI because the pre-installed pwsh in the CI builders is 6.0, and it cannot load the Microsoft.Azure.Functions.PowerShellWorker.dll along with the module. It can be fixed by updating our build.ps1 to install the 6.1 pwsh, but since we don't plan to merge this PR soon, I would rather wait for AppVeyor to adopt 6.1 by default.

[AnatoliB]

Thank you, @daxian-dbw! This prototype was very helpful and saved us lots of time!
I'm closing this PR now because this code is mostly committed as a part of #358.