Support development time TokenCredential

[jviau]

Description

To improve local development, core-tools should offer a way to support development time TokenCredential.

Background

Today Azure Functions supports credential via configuration. The exact credentials supported is intentionally aligned with what Azure SDK supports via AzureComponentFactory.CreateTokenCredential. This works for scenarios but is limiting for local development. The only local dev route is to 'trick' it into giving you a DefaultAzureCredential, and then hoping that resolves to the dev credential you want.

That later part is a challenge when you are developing on a machine with higher precedence credentials that you do not want to use (such as a valid managed identity endpoint).

Plan

We will add support to core tools to inject a custom ChainedTokenCredential for the host which includes only common dev-time credentials in it (exact creds TBD, but current theory is everything from DefaultAzureCredential less managed identity credential).

Injecting of the credential will be done via setting a global default credential with the .AddAzureClients() call:

services.AddAzureClients(b => b.UseCredential(/* dev time credential */));

Design Needed

1. What is the opt-in mechanism for customers is here?

Known Limitations

The mechanism this relies on is how AzureComponentFactoryImpl will fall back to _globalOptions.CurrentValue.CredentialFactory(_serviceProvider); when the ClientFactory.CreateCredential returns null. This poses two known limitations:

1. Whatever we do here will not take precedence over ClientFactory.CreateCredential, as it runs first. So if a customer has valid credential config for a trigger, that will preferred over the global dev credentials.
2. In the same theme, there will be no way to configure per-trigger dev credentials. There will only be one global dev credential
3. Not all extensions use AzureComponentFactory. These will not be in-scope for this work.

Related Issues

Azure/azure-functions-dotnet-worker#3027