45 support for garden linux images

[pnpavlov]

Fixes: #45

Includes the dockerfiles used for publishing https://github.com/orgs/SAP/packages/container/sapmachine/versions?filters%5Bversion_type%5D=tagged and a skeleton for a GitHub action that can publish images for future SapMachine versions against a specific Garden Linux release.

It should be possible to test the workflow with something like, but not done because of permissions and not sure if this makes sense to run or should be enhanced further first.

gh workflow run publish-container-images.yaml -r 45-support-for-garden-linux-images -f sapMachineVersion=21 -f gardenLinuxVersion=1592

Test performed:

1. CreatEd Gardener cluster with two nodes on arm64 and amd64

% kubectl get no -o wide
NAME            OS-IMAGE                    KERNEL-VERSION
ip-....internal Garden Linux 1592.1   6.6.47-cloud-arm64
ip-....internal Garden Linux 1592.1   6.6.47-cloud-amd64

then applying deployment with two replicas of ghcr.io/sap/sapmachine:21-jdk-gl-1592 with topologySpreadConstraints to make sure deployment happens to both nodes

% kubectl logs sapmachine21-7c6b9b7d96-44jdg
GL:
GARDENLINUX_CNAME=container-arm64-1592.1
Java:
OpenJDK Runtime Environment SapMachine (build 21.0.4+7-LTS)

% kubectl logs sapmachine21-7c6b9b7d96-6zddd 
GL:
GARDENLINUX_CNAME=container-amd64-1592.1
Java: 
OpenJDK Runtime Environment SapMachine (build 21.0.4+7-LTS)

[skateball]

to me:

• 22 is supported for two weeks => remove
• 11 is supported until year end => remove
• 17+21 should be enough, and for a BETA jdk-only should be okay
  @RealCLanger what do you think? what is about the changed debian install scripts?

[pnpavlov]

Thanks, tried to follow the structure you have and keep it consistent with the rest of the Dockerfiles. I'm happy with all options:
a. Update the Garden Linux Dockerfiles to follow the installation procedure at https://github.com/SAP/SapMachine/wiki/Installation , then merge until you get the automation in place.
b. Publish as-is and then you overwrite them in consistent way with the alternatives for other OSes.
c. Close the PR without merging it and wait for the publishing of the Dockerfiles via your full automation.

As the change in the installation procedure should have to my understanding limited impact on the container base image consumer, it may be sufficient to enhance the Dockerfiles with next update by your automation and just overwrite them.