Update AAD token request target resource uri for ACR access

[ShaunDonn2]

Description

In alignment with this documentation, we should use the ACR-specific target resource URI rather than the generic ARM URI in order to get the "xms_az_tm" claim on the token that we need to authenticate as a Trusted Service with ACR. This value is passed in and used as the scopes value for the token request in the AuthenticationProvider.

This PR effectively updates the name of the config field as "armResourceManagerId" is not descriptive of the purpose of this field, which is to determine the target resource URI for getting access tokens for the ACR. The "management.azure.com" value will still work here, so we will keep it as the default so as not to break any OSS or other scenarios. We will override this value in our PaaS code to point to the ACR-specific value which enabled Trusted Services scenarios.

Related issues

Addresses bug 126662.

Testing

Validated this change by passing in the values of a prod Credential Bundle and the updated target resource URI into the token request in the AuthenticationProvider. With the generic ARM URI, the token comes back without the xms_az_tm claim; with the ACR-specific URI, the request comes back with the claim included.

FHIR Team Checklist

• Update the title of the PR to be succinct and less than 65 characters
• Add a milestone to the PR for the sprint that it is merged (i.e. add S47)
• Tag the PR with the type of update: Bug, Build, Dependencies, Enhancement, New-Feature or Documentation
• Tag the PR with Open source, Azure API for FHIR (CosmosDB or common code) or Azure Healthcare APIs (SQL or common code) to specify where this change is intended to be released.
• Tag the PR with Schema Version backward compatible or Schema Version backward incompatible or Schema Version unchanged if this adds or updates Sql script which is/is not backward compatible with the code.
• [ ] CI is green before merge
• Review squash-merge requirements

Semver Change (docs)

Patch|Skip|Feature|Breaking (reason)

[ShaunDonn2]

Does the ACR audience need to be parameterized in config for GovCloud or other non-PublicCloud environments?

I was planning on doing this in the Health-PaaS repo, where we had the old ARM value parameterized, but I just saw in the docs that the value I have added is constant across Azure Clouds. I will still need to update the value in Health-PaaS, but it seems that we can have the same value for all environments.