LEGLINK-822: Add the mock DMRP API to the build-and-push script

Raised in review on PR #1800.

set_kubernetes_services.bat gained a mock-dmrp line earlier on this branch, but
build_and_push_and_set.py carries the same per-service inventory -- repo,
deployment and container, plus the Dockerfile and build context the .bat has no
need for -- and had no entry at all. Without one the mock could not be built,
pushed or deployed through the script, and --all-services silently skipped it.

Every value is taken from the deployment definitions rather than inferred:

  - link-mock-dmrp from registry-repo-Name in
    azure-pipelines.mockdmrpapi.cd.yaml
  - mock-dmrp-deploy and mock-dmrp from _deploy_all_services.yml, which builds
    "deployment $(serviceName)-deploy $(containerName)=..." out of
    serviceName: mock-dmrp and containerName: mock-dmrp
  - DotNet/MockDmrpApi/Dockerfile with a repository-root context, from
    docker-compose.yml

The docstring's recognized-services list is updated too. It is not decoration:
the same list is printed when an unrecognised --service is passed, and an
unknown service now reports mock-dmrp-api among the valid ones.

The entry carries a comment about where it differs from the others. The mock is
deployed to the lower environments only, and unlike the .bat -- which runs its
kubectl lines unconditionally and merely prints an error for a deployment that
is absent -- this script exits on a failed command, so selecting the mock
against a namespace without mock-dmrp-deploy would stop every service queued
behind it alphabetically.

Verified the module parses, --help runs, the SERVICES keys are still in
alphabetical order, and an unknown --service lists the new name.

One thing found and deliberately not changed: this inventory exists in three
places, and _deploy_all_services.yml -- the one CI actually runs -- has an
automation entry that appears in neither script. That drift predates this
ticket and is the opposite direction from the gap fixed here.

Author: MikeAtPinnacle

Scripts/build_and_push_and_set.py

@@ -23,8 +23,8 @@
 
 Recognized services:
     account, admin-bff, admin-ui, audit, census, dataacq, dataacq-worker,
-    measureeval, normalization, querydispatch, report, submission, tenant,
-    terminology, validation
+    measureeval, mock-dmrp-api, normalization, querydispatch, report,
+    submission, tenant, terminology, validation
 """
 
 import argparse
@@ -44,6 +44,10 @@
     "dataacq": {"repo": "link-dataacquisition", "dockerfile": "DotNet/DataAcquisition/Dockerfile", "context": ".", "deployment": "data-acquisition-deploy", "container": "data"},
     "dataacq-worker": {"repo": "link-dataacquisition-worker", "dockerfile": "DotNet/DataAcquisition.AcquisitionWorker/Dockerfile", "context": ".", "deployment": "data-acquisition-worker-deploy", "container": "data-worker"},
     "measureeval": {"repo": "link-measureeval", "dockerfile": "Java/measureeval/Dockerfile", "context": "Java", "deployment": "measure-deploy", "container": "measure"},
+    # Stand-in for the CDC DMRP API, deployed to the lower environments only. Selecting it
+    # against a namespace that has no mock-dmrp-deploy fails the kubectl step, and because
+    # that failure exits the script, it would stop any services queued behind it.
+    "mock-dmrp-api": {"repo": "link-mock-dmrp", "dockerfile": "DotNet/MockDmrpApi/Dockerfile", "context": ".", "deployment": "mock-dmrp-deploy", "container": "mock-dmrp"},
     "normalization": {"repo": "link-normalization", "dockerfile": "DotNet/Normalization/Dockerfile", "context": ".", "deployment": "normalization-deploy", "container": "normalization"},
     "querydispatch": {"repo": "link-querydispatch", "dockerfile": "DotNet/QueryDispatch/Dockerfile", "context": ".", "deployment": "query-dispatch-deploy", "container": "query-dispatch"},
     "report": {"repo": "link-report", "dockerfile": "DotNet/Report/Dockerfile", "context": ".", "deployment": "report-deploy", "container": "report"},