[azure-functions-durable] Orchestrator context parameter name is fixed to `context`, blocking access to `func.Context`

Summary

In the azure-functions-durable (V2) package, the parameter that receives the
orchestration context is effectively hardcoded to the name context. As a
consequence:

• A user-supplied context_name other than "context" on
  @app.orchestration_trigger(...) does not work — the host cannot bind the
  trigger to the generated handle.
• There is no way for an orchestrator to also receive an
  azure.functions.Context (func.Context) parameter, because the Functions
  host injects func.Context only into a parameter named exactly context
  that is not a trigger binding — and that name is always consumed by the
  orchestrationTrigger binding.

This matches V1 behavior (see "Not a regression" below), so it is not a
regression introduced by V2. Filing this to track it as a potential V2
improvement to be considered after the Functions PR merges and the beta
release ships.

Mechanism / relevant code paths

The Azure Functions host binds a trigger to a function parameter by name,
and it inspects the generated handle (not the user's function).

1. The trigger binding is registered with name=context_name:

   • azure/durable_functions/decorators/durable_app.py —
     orchestration_trigger(context_name, ...) calls
     OrchestrationTrigger(name=context_name, ...).

2. The generated handle that the host actually indexes hardcodes a parameter
   literally named context:

   • azure/durable_functions/orchestrator.py — Orchestrator.create:

     def handle(context: func.OrchestrationContext) -> str:
         return Orchestrator(fn).handle(context)
     

   • The parameter must be annotated azure.functions.OrchestrationContext
     for the host's orchestrationTrigger binding converter to accept it.

3. Because the host matches the binding name (context_name) to a parameter
   of handle by name, they only line up when context_name == "context".
   Any other context_name leaves the trigger unbound.

4. func.Context injection: the Python worker injects func.Context only into
   a parameter named exactly context that is not itself a trigger binding.
   Since the orchestrationTrigger always occupies the context name, there is
   no free context parameter for func.Context to be injected into.

5. Separately, durabletask's executor invokes the user's orchestrator as
   fn(ctx, input) — there is no slot in that calling convention for a
   func.Context object to be passed through to user code.

Not a regression (V1 parity)

V1 has the same structural constraint. In
azure-functions-durable-python's azure/durable_functions/orchestrator.py,
Orchestrator.create also registers a single-parameter
def handle(context: func.OrchestrationContext), so a V1 orchestrator could
never receive a working func.Context parameter either. V2 preserves this
behavior.

Related parity gap: function_context contents

The V1-compat DurableOrchestrationContext adapter currently exposes an empty
function_context. V1's function_context is not necessarily empty: in
azure/durable_functions/models/DurableOrchestrationContext.py, __init__
consumes a fixed set of named fields (history, instanceId, isReplaying,
parentInstanceId, input, upperSchemaVersion, maximumShortTimerDuration,
longRunningTimerIntervalDuration, upperSchemaVersionNew) and funnels every
remaining field of the orchestration-trigger JSON into
FunctionContext(**kwargs). As of today the WebJobs extension injects at least
one such field — defaultHttpAsyncRequestSleepTimeMillseconds (observed value
30000, the durable-HTTP async polling interval) — so a live V1
function_context carries that value.

V2 receives the orchestration input via a protobuf trigger that does not carry
these arbitrary extra fields, so the compat adapter has no source to populate
function_context from. This is a minor parity gap to consider alongside the
context-name / func.Context work above.

Notes

• Out of scope for the current parity-focused Functions PR; capturing here so
  it can be picked up as a V2 improvement after the beta release.

Beginne mit azure/durable_functions/decorators/durable_app.py und azure/durable_functions/orchestrator.py, insbesondere mit orchestration_trigger und Orchestrator.create. Verfolge, wie der generierte handle indiziert wird und wie durabletask die Benutzerfunktion aufruft, und prüfe anschließend den V1-Kompatibilitätsadapter sowie dessen Handhabung von function_context in DurableOrchestrationContext. Als abgeschlossen würde gelten, wenn ein abgestimmter V2-Ansatz für benutzerdefinierte Kontextnamen, den Zugriff auf func.Context und die damit verbundene Lücke bei der function_context-Parität vorliegt.