Add parameter and functionality to enable triggering user access for Azure resources

[jestradaMS]

Description

This pull request introduces a new feature to the deployment pipeline that automatically grants the triggering user's account access to CosmosDB and SQL databases during environment provisioning. This enhancement is controlled by a new parameter and is enabled across all relevant deployment stages, improving developer experience and streamlining access management for deployed environments.

Access Management Enhancements

• Added a new boolean parameter addTriggeringUserAccess to build/jobs/provision-deploy.yml to control whether the triggering user is granted access during provisioning.
• Implemented logic to add the triggering user as a Data Contributor in CosmosDB if the parameter is enabled, including handling for guest users and existing role assignments.
• Added logic to create or update the triggering user as a SQL database user with db_owner role, using Azure AD authentication and robust error handling.

Pipeline Configuration

• Enabled addTriggeringUserAccess: true for all deployment stages in build/pr-pipeline.yml, ensuring the feature is active for all environment types and database backends. [1] [2] [3] [4] [5] [6] [7] [8]

Related issues

Addresses AB#166378.

Testing

Describe how this change was tested.

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.
• When changing or adding behavior, if your code modifies the system design or changes design assumptions, please create and include an ADR.
• CI is green before merge
• Review squash-merge requirements

Semver Change (docs)

Patch|Skip|Feature|Breaking (reason)