Azure Functions + Aspire initial integration follow-ups

[captainsafia]

This is a meta-issue to track some of the pending tasks from the initial work to add Azure Functions support to Aspire.

• - Dual connection strings dilemma (Support connection name-based configuration for Azure components #5827)
• - Handling port defined in launch profile (Support loading port info from launch profile for Azure Functions #5873)
• - Add support for Service Bus resources (Support Service Bus resources in Azure Functions #5593)
• - Ensure implementation is resilient to storage configured with same name as default

Dual connection strings dilemma (#5827)

The current implementation relies on custom mappings of connection strings from the Aspire format to a format that the Azure Functions host (which uses the underlying Azure SDKs) can consume. This enables resource references to be passed through to the Azure Functions host, which facilitates interactions with the resources. However, Aspire-based connection strings are also required if we want to enable access to Aspire-injected resources in Azure Functions workers.

Currently, an uninvestigated bug occurs when both connect string key/value formats are injected in to the Azure Functions host. Azure Functions workers currently inherit connection strings from the host so the host must be able to successfully handle both formats in order to support the entire E2E.

Handling port defined in launch profile (#5873)

The default Azure Functions templates allow the user to define the port the Azure Functions host will listen on for processing HTTP triggers. Aspire's launch profile infrastructure doesn't expose APIs for being able to read this property value and expose the user-configured port as an HTTP endpoint. This means that we can only support ports that are randomly assigned and injected into the host service by Aspire. For an application to work successfully, there must be no port defined in the launch profile.

We should explore making changing to the launch profile APIs to support being able to introspect launch settings.

Add support for Service Bus resources (#5593)

Service Bus resources are not currently supported because there is no support for emulation of Service Bus, which makes end-to-end testing of the integration difficult (all the other testing issues aside 😅). There's also miscellaneous issues with referencing the ServiceBus extension for Azure Functions locally in our repo that need to be resolved.

Ensure implementation is resilient to storage configured with same name as default

The implementation currently auto-configures a storage resource with the name azure-functions-default-storage when no storage resource is configured. This can present a problem if the user tries to allocate a storage resource with the same name:

builder.AddAzureStorage("azure-functions-default-storage");

builder.AddAzureFunctionsProject<Projects.MyFuncs>("MyFuncs");

This is not likely to happen but we should investigate if it is worth being resilient to this.

[captainsafia]

The critical issues tracked in this issue have been completed. Gonna close this now and track other items separately.