add-ons/azure_devops_v1: add service endpoints for Azure container registry

[sschne]

• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.
• My code follows the code style of this project.
• I ran lint checks locally prior to submission.
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Description

Introduces a new component service_endpoints_acr to add a Docker Registry service connection to Azure DevOps from an Azure Container registry created in a previous landing zone.
It uses the azuredevops_serviceendpoint_dockerregistry resource rather than the azuredevops_serviceendpoint_azurecr resource, as the latter requires to be able to create a service principal for connecting to the ACR on demand, which seems not feasible to me.

The component requires an existing azure_container_registries with admin_enabled.

Does this introduce a breaking change

• YES
• NO

Testing

[ghost]

All CLA requirements met.

[iriahk89]

LGTM

conflict with another PR

[iriahk89]

I think this pattern from another PR: #264 would be a better solution as it will reduce the maintenance to remove additional variable every time we have a new target endpoint (GitHub, ACR etc.)

[brk3]

Hi! This looks good to me and actually covers off a similar use case I'm currently working through (#290).

If I'm reading @iriahk89's comment correctly you just need to replace your variable service_endpoints_acr with a for_each across var.service_endpoints, checking if your type attr matches a predetermined value (https://github.com/Azure/caf-terraform-landingzones/pull/264/files#diff-e6f612f660ccb2be61580cacce596b956a2f967414cc2c6e895103dd78f8aa9eR4-R7). We could go with "Docker" or "acr".

[sschne]

@iriahk89 I have updated the resource according to the given pattern

[LaurentLesle]

LGTM