Use master-built base images in Debian/Ubuntu packaging CI jobs + enable Datadog observability

Summary

• Standardize all Debian/Ubuntu packaging pipeline jobs on the base images built from the master branch.
• Provide out-of-the-box observability for these jobs via Datadog (logs/metrics/traces) to improve visibility and incident triage.

What changes

• CI: Update packaging jobs to pull the master-built Debian/Ubuntu base images instead of ad-hoc/pinned per-job images.
• Observability: Export Datadog environment variables and bootstrap the agent/instrumentation so telemetry is emitted from packaging jobs.
• Minor CI refactors to centralize image selection and Datadog settings (where applicable).

Why

• Consistency: All packaging jobs run on the same vetted base images built on master.
• Reliability: Reduces drift and surprises across jobs/environments.
• Observability: Datadog telemetry by default for faster debugging and better tracking during jobs runs.

How to validate

• Run the Debian/Ubuntu packaging pipeline on this branch. test pipeline : https://gitlab.com/tezos/tezos/-/pipelines/1974495185
  • Notice that we build amd64/arm64 images using the multi-arch base images
• In job logs, confirm the image used corresponds to the master-built base image for Debian/Ubuntu.
  • Search for #3 [internal] load metadata for us-central1-docker.pkg.dev/nl-gitlab-runner/protected-registry/tezos/tezos/debian:bookworm to validate that the correct image is actually used in the dependency build jobs : https://gitlab.com/tezos/tezos/-/jobs/10961870286
  • Search for Tags sent in jobs using the dependency images https://gitlab.com/tezos/tezos/-/jobs/10961870352
  • Search for Tags sent in jobs using base images : https://gitlab.com/tezos/tezos/-/jobs/10961870515

Other points to consider:

• Since we relay on base images built for the maser branch, it is not possible to modify the test images and test them immediately. 2 MRs are required.
• I've a proposition to allow for atomic upgrade of the base images so to re-introduce A-B testing in a follow-up MR
• A second MR will follow for the rpm packages mirroring exactly the work done in this MR.