Use middleware to replace OrchestrationRunner.loadAndRun in orchestrator functions

[cgillum]

See https://github.com/Azure/azure-functions-java-worker/issues/595 for reference.

The idea is to simplify the orchestrator function programming model from this:

@FunctionName("Chaining")
public String helloCitiesOrchestrator(
        @DurableOrchestrationTrigger(name = "runtimeState") String runtimeState) {
    return OrchestrationRunner.loadAndRun(runtimeState, ctx -> {
        String input = ctx.getInput(String.class);
        int x = ctx.callActivity("F1", input, int.class).await();
        int y = ctx.callActivity("F2", x, int.class).await();
        int z = ctx.callActivity("F3", y, int.class).await();
        return  ctx.callActivity("F4", z, double.class).await();
    });
}

...to something that looks like this...

@FunctionName("Chaining")
public double helloCitiesOrchestrator(
        @DurableOrchestrationTrigger(name = "runtimeState") String input) {
    int x = ctx.callActivity("F1", input, int.class).await();
    int y = ctx.callActivity("F2", x, int.class).await();
    int z = ctx.callActivity("F3", y, int.class).await();
    return  ctx.callActivity("F4", z, double.class).await();
}

[kaibocai]

Hi @cgillum , as far as I know, this middleware support is only available on isolated dotnet worker. I wonder for in-pro dotnent worker how durable function register the middleware? Thank you.

[cgillum]

@kaibocai the in-process worker allows trigger authors to inject trigger-specific middleware and has a lot of flexibility for controlling inputs and outputs. It’s even more flexible than the .NET Isolated worker (but also much more complicated).

[cgillum]

I've added this to the v1.0.0 (STABLE) milestone. The reason for prioritizing it is because it will be difficult to apply this change later.