Add image mirroring support

[sarahchen6]

Description

dd-trace-java CI now requires images to be signed. Images can be signed by first mirroring them into registry.ddbuild.io. This PR adds support for this new process with:

• An updated README with instructions on how to test and tag CI images
• A workflow for updating CI image digests. It is triggered manually or by the completion of the existing docker-tag workflow. It automatically opens a PR in DataDog/images with updated ci-* image digests.
• A workflow for adding/updating test image digests. It is triggered manually with an input PR_NUMBER that corresponds to the dd-trace-java-docker-build PR being tested. It automatically opens a PR in DataDog/images with new or updated image digests that correspond to PR_NUMBER.

Testing

Both workflows use scripts to update the DataDog/images repo and get latest image digests. These scripts were tested successfully locally by calling them from a cloned copy of DataDog/images. The workflows need to land on master before being test-able.

See comments in #141 for workflow testing.

Follow-ups

• The automatically created PRs are currently opened as Drafts. Once we confirm that the workflow and PRs are accurate, we can open them directly as "Ready to Review". This should help automate the process further with the DataDog/images PR-approver bot.
• The DataDog/images trust policy also needs to be refined to only master after testing (ref).

[PerfectSlayer]

❔ question: ‏About this step, what motivated you to switch from bash to python as you had a working version in bash previously?

🎯 suggestion: ‏It might be easier to run a script that is versioned in the repository rather than adding it inline into yml? 🤷 And as they are similar scripts in the update-mirror-digests workflow, you can reuse it there too

[sarahchen6]

❔ question: ‏About this step, what motivated you to switch from bash to python as you had a working version in bash previously?

No good reason - I started with trying to bring the bash over, but found it easier to format and test out python with Claude... I think I ended up over-engineering with python though, so will switch back to bash!

🎯 suggestion: ‏It might be easier to run a script that is versioned in the repository rather than adding it inline into yml? 🤷 And as they are similar scripts in the update-mirror-digests workflow, you can reuse it there too

Hmm that could make the workflows more readable too 🤔

[PerfectSlayer]

so will switch back to bash!

make the workflows more readable

Yeah, think about what could be the simplest bricks to be reused by the workflows.
Ideally, if we could run them outside the workflow (when needed or to test them) like you did for the pin system test script, that would be ideal.

About python or bash, whatever. Just pick one that work well for the task and that will be easy to maintain by the team :)

[sarahchen6]

In 8e3e105, I split the logic into 3 scripts:

The create-test-mirror-pr.yml workflow calls create-test-mirror-entries.sh which either adds test image entries or updates the existing test image digests in DataDog/images.

The update-mirror-digests.yml workflow calls update-ci-image-digests.sh which updates the existing ci-* image digests.

Both workflows source get-image-digests.sh which uses crane to get the latest digests for all CI variants in ghcr.io, given the prefix ci- or PRNUM_merge-.

The scripts were successful locally!

[PerfectSlayer]

That looks good. Thanks for keep refining the developer experience around testing!