Remove old_azure_cli feature from azure_identity

[heaths]

Because the caller of azure_identity can't know what version of the Azure CLI is installed, we should remove the old_azure_cli feature and support both expiresOn and expires_on as does Go: https://github.com/Azure/azure-sdk-for-go/blob/d34a8dd747cbaaac577a8b53ec56b970bff09eaa/sdk/azidentity/azure_cli_credential.go#L179-L185

This does mean more dependencies but I don't think is something we can avoid.

[heaths]

@chlowell @joshfree do you agree? Basically, we use a feature named old_azure_cli that is part of the default features and reads the expiresOn field of the access token, but that causes us to pull in more date-time dependencies. The old code treats it as optional, but it seems to me that shouldn't be up to the dev using our SDKs, but we should support whatever version the end user has installed.

At some point do we cut support for that version of Azure, though? According to a comment in our azure_identity crate, that version is from before November 2023:

# If you are using and Azure CLI version older than 2.54.0 from November 2023,
# upgrade your Azure CLI version or enable this feature.
# Azure CLI 2.54.0 and above has an "expires_on" timestamp that we can use.
# https://github.com/Azure/azure-cli/releases/tag/azure-cli-2.54.0
# https://github.com/Azure/azure-cli/issues/19700
old_azure_cli = ["time/local-offset", "tz-rs"]

/cc @cataggar

[chlowell]

Makes sense to me. The credential working seamlessly in both cases because it handles the old/new distinction internally is obviously a better user experience, modulo the additional dependencies.

At some point do we cut support for that version of Azure [CLI], though?

🤷 I expect to continue supporting the old format indefinitely because we can't tell whether anyone is using it