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

Bắt đầu với azure/durable_functions/decorators/durable_app.py và azure/durable_functions/orchestrator.py, đặc biệt là orchestration_trigger và Orchestrator.create. Theo dõi cách handle được tạo ra được lập chỉ mục và cách durabletask gọi hàm người dùng, sau đó xem xét adapter tương thích V1 và cách xử lý function_context của DurableOrchestrationContext. Công việc được xem là hoàn tất khi đã thống nhất một phương án V2 cho tên context tùy chỉnh, quyền truy cập vào func.Context và khoảng trống về tính tương đương liên quan đến function_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.