Build images like icinga-kubernetes (3rd party GHA, less own scripts)

This wouldn't be a problem for X.Y.Z tags as they obviously don't concur with each other. X.Y ones are also not affected as we don't build e.g. 2.14.3 and 2.14.4 at the same time. Only latest is problematic. Sure, we already build all Docker tags mutually exclusive, so that e.g. 2.13.8 is not pushed to latest just after 2.14.0 if released at the same time.

But the 3rd party GHA icinga-kubernetes uses needs to know in advance whether to push latest and can't decide based on present tags in Docker Hub. I see these options:

1. Use the GHA like this in support branches ex. the latest support branch: https://github.com/renchap/mastodon/blob/3b9b4eda096e4c11ac4876d39e3bd71a4a1c5872/.github/workflows/build-image.yml#L52-L55
   • A maintainer confirmed you have to do it like this: https://github.com/docker/metadata-action/issues/80#issuecomment-838764150
   • Implications:
     • Before tagging a new .0 of Icinga 2, we'd have to update the previous support branch and disable latest tagging there
     • The latter implies that it also happens before tagging on this support branch if such collides with the .0 (e.g. 2.13.8 & 2.14.0 released at the same time)
2. Disable latest tagging in that GHA completely for our case
   • Implication: we'd still need the mktags script for latest

TODO

• Await next icinga-kubernetes release
• Look how well its GHA worked
• Make the decision described above

Wait for the next icinga-kubernetes release, then review how its GitHub Actions workflow handles image tags. Compare that behavior with the current mktags script and the two options described in this issue; done means choosing an approach and updating the image-building workflow and tagging process accordingly.