Spike: Set the client id for functions configuration

[davidfowl]

Description

This pull request introduces changes to enhance Azure Functions integration by adding support for the clientId environment variable. The updates ensure that the clientId is correctly injected into the environment variables for Azure Functions projects when applicable.

Fixes #8116

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No
• Does the change require an update in our Aspire docs?
  • Yes
    • Link to aspire-docs issue (consider using one of the following templates):
      • New (or update) doc-idea template
      • New breaking-change template
      • New diagnostic template
  • No

[davidfowl]

This is a little hacky. Unclear if this signal is needed. We might be able to do something else like always set it in WithReference if it is harmless (we already always set AZURE_CLIENT_ID today anyways?)

cc @fabiocav @mattchenderson

[mattchenderson]

It should generally be harmless to just set it in WithReference() today, but it's probably worth building some defensiveness in here. I actually realize we forgot to prescribe something for this scenario: I believe we still need {connectionName}__credential: managedidentity, as that's the signal used to engage this when AZURE_CLIENT_ID is missing. I don't know if the KEDA logic cares there, but that is how Microsoft.Extensions.Azure expects things.

I'm imagining a situation in which someone themselves specifies {connectionName}__credential, set to something that gets added in the future. AZURE_CLIENT_ID likely would be mapped the same, but I don't know that it's guaranteed (and I'm thinking of cross-tenant with MI+FIC, specifically). I think the safest approach would be to check the credential type. If it's not unspecified or "managedidentity", we wouldn't want to assume {connectionName}__clientId has these semantics, or that it should be set at all. If the user goes custom here, they become responsible for the full suite of config for that custom approach.

[davidfowl]

I don't know if the KEDA logic cares there, but that is how Microsoft.Extensions.Azure expects things.

Are you pretty sure the KEDA doesn't support AZURE_CLIENT_ID?

[mattchenderson]

That was the case when we opened the issue, at least. I've not been made aware of any updates on that front if they did happen.

[davidfowl]

We should fix keda and make it respect AZURE_CLIENT_ID