Token exchange support for ManagedIdentityCredential

[chlowell]

With this change, ManagedIdentityCredential authenticates via a token exchange when these variables are set:

• AZURE_CLIENT_ID
• AZURE_TENANT_ID
• TOKEN_FILE_PATH: path to a file containing the JWT to be exchanged
  • the credential caches this file's content for 5 minutes i.e. it reads the file only after 5 minutes have passed since the last time it read the file
• optional: AZURE_AUTHORITY_HOST

I implemented this atop a new credential class, ClientAssertionCredential, which authenticates with a JWT assertion. It's quite similar to CertificateCredential but instead of constructing a JWT for the "client_assertion" field, this new credential gets one from a callback. I kept ClientAssertionCredential internal because there's no need to make it public today; we may find one in the future.

Closes #19304

[mccoyp]

Do you think it would be valuable to do any logging in the case where the credential isn't (or is) available? Users will find out if it's unavailable when a token request is made, but EnvironmentCredential logs availability status (though that's part of the DefaultAzureCredential chain, which might have been the motivation to log there)

[chlowell]

Summarizing offline conversation: it's moot because ManagedIdentityCredential is the public API of this credential and already logs the interesting bit (what platform it believes it's running on) and will only instantiate this credential when its required environment variables are set. TokenExchangeCredential can therefore assume its prerequisites are met, and stop trying to raise a useful error message when that isn't the case. Commit to that effect forthcoming.

[mccoyp]

Should we do a check for self._credential here (and if we shouldn't, should we do that check in the sync credential)? Also, is there a reason that async credentials follow a close() -> self._x.close() pattern instead of close() -> self.__aexit__() -> self._x.__aexit__() pattern like sync credentials do?

[chlowell]

We should check that, thanks for noticing! There's no good reason for the sync vs. async difference. I prefer close -> exit today but it doesn't really matter.

[mccoyp]

Should this require a tenant_id, client_id, and get_assertion since ClientAssertionCredential does?

[chlowell]

Sure, that will make it easier for future generations to understand how this works.

[mccoyp]

Are you keeping the async context management API since it's more relevant for async credentials?

[chlowell]

That and self._client here already implements the API. I removed it from the sync credential because I don't want to block this PR on #19746 or paste part of that PR into this one.