SDK inconsistency across langs: support AZURE_CLIENT_SEND_CERTIFICATE_CHAIN from DAC

[maurolscla]

Is your feature request related to a problem? Please describe.
In order to implement SNI cert-based auth one has to leverage ClientCertificateCredential instead of DefaultAzureCredential. This happens because the latter does not support the AZURE_CLIENT_SEND_CERTIFICATE_CHAIN env var so that appropriate x5c header is sent. If a codebase has to support both SNI and MSI auth it follows it must have different code paths for each. This makes the auth logic convoluted and can lead to code obscurity.

Describe the solution you'd like
Add support for AZURE_CLIENT_SEND_CERTIFICATE_CHAIN when using DefaultAzureCredential() so that it can pick up said env var and send the appropriate x5c header.

Additional context
Other azure SDKs already have support for that (golang and .NET). It makes sense to make this behaviour uniform acroos all SDKs.

[joshfree]

Other azure SDKs already have support for that (golang and .NET). It makes sense to make this behaviour uniform acroos all SDKs.

Thanks for reporting this issue, @maurolscla. @scottaddie @christothes @g2vinay can you please follow up?

[joshfree]

@KarishmaGhiya this tracking issue likely needs to be duplicated for other language repos