Feat cross app wf

[cicoyle]

expose cross app functionality in durabletask and update contributing docs with how to update protos

Implementation for this proposal

[JoshVanL]

Why is this AppID and not Target or similar?

[cicoyle]

I left the OrchestrationCtx AppID as-is, and did not change it to sourceAppID. I did however change this to be targetAppID. I prefixed it with target to be clear its the target, not a source per say, but also left AppID to be clear what the 'target' is.

As of now its used like:

err := ctx.CallActivity("ProcessData",
			task.WithActivityInput(input),
			task.WithAppID(appID2)).
			Await(&output)

lmk if you think it would be clearer to use task.WithTargetAppID(appID2)) or task.OnAppID(appID2) instead

[JoshVanL]

What are we doing here?

Why are we checking whether AppID is an empty string?

[cicoyle]

I tweaked the if statement, but I assigned ctx.AppID during the ExecutionStarted event because that’s when we can be sure we’re handling the current orchestration — not a parent or child in the call stack.

While router metadata is technically available on every history event, setting AppID earlier (for ex: in NewOrchestrationContext()) could be misleading in the presence of sub-orchestrations. To do that cleanly, I’d either need to pass AppID into NewOrchestrationContext (which would require changes across multiple ExecuteOrchestrator implementations in backend/orchestration.go, client/worker_grpc.go, and azurefunc/middleware.go) or scan through oldEvents and newEvents, which felt fragile and error-prone.

Open to suggestions if there's a cleaner place you think it belongs — happy to tweak!