[Azure Functions] Simplify large-payload configuration by reusing an existing storage connection

The issue is about simplifying configuration in the azure-functions-durable SDK. Start by reading PR #270 and the existing DFApp.configure_large_payloads method. Understand how Azure Functions storage connections (AzureWebJobsStorage) and the Durable backend are configured. The goal is to design a helper that reuses an existing connection without requiring manual BlobPayloadStore construction. Check the linked Microsoft documentation for host storage settings and Durable Azure Storage connection configuration.

Community feedback wanted

Would you use a simpler way to configure large-payload storage in the azure-functions-durable v2 SDK using a storage connection your Function App already has?

Please add a thumbs-up reaction to this issue if this would help, and comment with your use case. In particular:

• Would you use the Function App's host storage (AzureWebJobsStorage), a separate Azure Storage backend account, or another named connection?
• Do you use a connection string, system-assigned managed identity, or user-assigned managed identity? Is local development with Azurite important?
• Would explicitly choosing a connection name be sufficient, or is automatic discovery of the Durable backend's account important?
• Is constructing a BlobPayloadStore explicitly a meaningful obstacle today?

This issue is gathering demand and requirements, not committing to an API or delivery timeline.

Context

PR #270 adds explicit configuration through DFApp.configure_large_payloads(payload_store=...). We are keeping that implementation simple: applications supply their own payload store.

A potential follow-up would reuse existing Functions storage configuration so users do not need to construct a blob store or repeat connection-resolution code. Host storage and the Azure Storage Durable backend often use the same account, but can be configured separately.

Possible direction

Illustrative API only; these convenience forms are not implemented:

app.configure_large_payloads()  # Opt in, using AzureWebJobsStorage

app.configure_large_payloads(connection_name="DurableStorage")

Calling the API would remain an explicit opt-in to SDK payload externalization. The existing payload_store=... form would remain available for full control, mutually exclusive with connection-based configuration.

Automatic discovery of the Azure Storage backend's account is a separate option to evaluate based on feedback, rather than a prerequisite for a named-connection helper.

Design considerations

• Resolve both connection strings and identity-based connection settings, including identity selection and local development behavior.
• Backend discovery would need to honor effective host configuration, environment overrides, and supported aliases. The Python SDK does not currently receive a resolved backend storage configuration.
• Account selection must be stable across workers and deployments so existing payload references remain readable. Client bindings targeting other connections also need consideration because payload configuration is currently process-wide.
• Use a dedicated SDK payload container, not the backend's large-message container. Sharing an account does not make backend purge clean up SDK payload blobs; permissions and retention remain important.
• Azure Storage backend large-message handling and SDK payload externalization are separate mechanisms. This proposal only simplifies configuration of the latter.

References: Functions host storage settings and Durable Azure Storage connection configuration.