Shrink container image

[peterzandbergen]

The current container image size is around 1.3GB. I found this quite large.
With the help of OpenCode I split the Docker image into a jre and native version.

Changes

1. Dockerfile has two targets: jre and native
2. Entrypoint checks the mode parameter against the image type
3. Github Actions files build two image version
4. Github Action files use Action variables with original defaults for the container registry and credentials
5. Commented the use in docker compose file

Result: JRE image size 611MB, native image size 621MB, original size was 1.33GB)

Performed tests

1. Followed the contribution instructions with modified compose file for build (not in commit), tests passed.
2. Pushed to my repo and ci.yaml built succesfully. Images are here: Images
3. Runs in production (home nas) in native mode on ARM cpu (Asustor nas)

NOTE: I left the AGENTS and analysis file in for your information. Please feel free to remove them.

[poggenpower]

Really like the idea to have a smaller image.
Technically it would be a breaking change, because Users who use native will download the wrong image e.g. if they pull :latest

Maybe this should be merged with the switch to rootless image, which is already announced. Even if rootless should not break anything by design, it is a huge change.

@peterzandbergen the rootless stuff lives in its own branch at the moment: https://github.com/bbernhard/signal-cli-rest-api/tree/rootless_s6

[bbernhard]

Pfuh, that's a tough one. I can see the need for a smaller image size, but having everything in one image greatly improves the debugging capabilities, as one can easily switch between different modes. That's quite handy, as sometimes modes break (e.g due to upstream issues) and users can easily switch to other modes as a workaround until it is fixed. Since a significant portion of users are non -tech-savvy users, having everything in one image helps to guide them through the debugging steps/workarounds they can apply to get it working again.

[peterzandbergen]

As always, things are not as simple as I though it would be. I understand @bbernhard 's arguments for the less tech savvy users and having both runtimes available in one image being beneficial for debugging.

I suggest to have three image versions:

1. the orginal one with both runtimes which will have the "version" and the latest tag
2. the jre version, tag will be "version"-jre
3. the native version, "version"-native

[peterzandbergen]

I have added the all build target that builds the original image with the native and jre version.
I have also added --layers to optimize layer reuse for the podman commands.