Create CDS Archive for JVM app class pre-loading

[MirandaStreeter]

Short description

It's possible to memory-map the JVM application classes (ie jruby, clojure, puppetserver, etc) instead of unpacking them from the jar files on startup. The base classes are already shipped with whatever JRE you run. Doing this for the application itself shaves ~10% of startup time in my testing (at the cost of ~100MB space). This uses an extra stage during the containerfile build steps.

See: https://docs.oracle.com/en/java/javase/21/vm/class-data-sharing.html

The hard part, and what made this take so long to work out, was figuring out why the SIGTERM handler wasn't cleanly shutting down the JVM. It was nothing to do with dumb-init behavior, and nothing to do with the Alpine container's busybox version of pkill. No, we only need to target the child process, not the puppetserver wrapper that calls runuser. And as an added bonus the shutdown seems to be faster as well. :)

Part of #139

Checklist

I have:

• read the CONTRIBUTING.md document
• read and accepted the Developer Certificate of Origin document and added a Signed-off-by annotation to each of my commits
• read and accepted the AI Policy document and added Generated-by or Assisted-by annotations to each of my commits created with the help of an AI agent
• tested this code
• included documentation (including possible behaviour changes)
• documented the code
• added or modified regression test(s)
• added or modified unit test(s)

[rwaffen]

LGTM,

The ENV and LABEL which are now in the cds container will be kept when doing FROM in the final container?

[MirandaStreeter]

LGTM,

The ENV and LABEL which are now in the cds container will be kept when doing FROM in the final container?

Yes, they're kept, they live in the app stage which is the shared base for both the cds and final stages.

[rwaffen]

LGTM