Use OCI and OpenShift labels as part of Docker image metadata

[npepinpe]

Is your feature request related to a problem? Please describe.

As an OpenShift operator, I want to have more information about the applications deployed to my project, as well as tighter integration with the built-in console, in a format I understand, as I may not always know about the specific applications being deployed even as I must maintain them operationally.

Describe the solution you'd like

Image labels are a great and cheap way to convey this information, e.g. minimum amount of cores, memory, is the application scalable, what type of software is it, support/contact info, etc. See the context for more info about this.

Describe alternatives you've considered

We can document our images and their capabilities, as we should (and do). The labels however improve the discovery process for these things.

Additional context

• RedHat recommended image best practices
• Snyk image label integration
• OCI annotation scheme

[npepinpe]

Proposal is to add both the OCI labels and the OpenShift labels to our Dockerfile, ignoring the development stage for now. I think we can remove that stage anyway once our own development cluster is on GKE 1.22+ where we can use ephemeral containers, which will simplify our Dockerfile a bit.

Testing will be done via a pseudo-golden file (i.e. a golden file generated during the build of the expected values), and then comparing against the output of docker inspect camunda/zeebe:current-test | jq '.[0].Config.Labels'. I did look into both hadolint and container-structure-test, but:

1. hadolint only checks the Dockerfile, as such it can only say that you will set some values, but it can't tell you much about dynamic values, for example, and makes no guarantees of your final artifact.
2. container-structure-test is more interesting and actually checks the image (it can even start the container if you want to verify the entrypoint and other runtime properties), supports junit output, but it's a not officially supported anymore by Google, requires python, and is a bit limited in terms of flexibility. It doesn't support passing arguments and can only verify regex patterns. Plus, it means learning a whole new tool, and unlike hadolint, it doesn't "get out of your way", you have to understand how it works. So I would not propose this unless we had more complex tests to run.