Will be replaced with a capability to make API endpoints
for authentication providers read from MPCONFIG sources.

Payara 5 defaults to a "payara5" topmost dir, Payara 6 to
"payara6". To avoid adding different directories in the
assembly, cut the number from the directories name when
unpacking.

This does not prevent you from doing stupid things like
not cleaning before switching the version leading to an
unknown state of old and new libs, etc.

There was an ongoing discussion that the Docker Hub Image "openjdk"
is not backed by any official supported project but complete
goodwill of Oracle shipping their JRE/JDK.

There is no "real" release of OpenJDK . There exist only real
distributions like Oracle JDK, Eclipse Temurin, Azul JDK,
AWS Corretto etc (see https://whichjdk.com).

As for this reason the "openjdk" image has been deprecated,
switching to Eclipse Temurin JRE here.

See also: docker-library/openjdk#505

With the rise of Apple M1/M2 silicons, we need to provide ARM64
based images in addition to AMD64.

…as in Payara

- Change order of guides
- Remove unnecessary quotes from IQSS
- Add TOC to base image docs
- Add flag again about community support only to base image docs

Add new Maven properties to choose a different Java base image
and change the name of the target base image when people customize it.
Also changes the build arg for the Java base image name.

With this, the image name changes to follow the same convention
as the Java base image.

By switching to `mvn install` instead of `mvn package`, we allow
the main image carrying the application to declare a dependency
on the container-base module (to make sure it get's built alongside,
as we might want to change the Payara version!)

This commits also adds the Maven install plugin to the parent POM
for versioning plus to the container-base POM for having the target available.
(This is a necessary workaround for a Maven Docker Plugin shortcoming.)

By using the flattening POM plugin, the installed POM will
not carry references to the dataverse-parent module.
This reference is a) unnecessary and b) troublesome because of
the ${revision} hack. (And we do not provide it as a dependency
from Central/...)

Also mentioning the Github Action secrets as requested by @pdurbin.

Including here to add to reactor builds.

The base image uses Payara Community edition which might come
with expired CA certificates. These trigger ugly log messages
on startup. Removing them at build time helps with this.

The production-ready domain should have autodeploy and hot reloading
turned off for security reasons. On the other hand, hot reload is
very useful for development. Introducing an env variable
 ENABLE_RELOAD to enable it on request.

Instead of acivating the JMX settings by default, switch back to off.
Extending this with enabling AMX and with all the log levels set to HIGH,
this might cause a huge performance overhead.
Also lacking is a MicroProfile Metrics mapping to retrieve JMX data
via the /metrics endpoint for collection.

Adapting most of
https://blog.payara.fish/fine-tuning-payara-server-5-in-production here

By disabling the unnecessary HTTPS listener, we'll save
some memory and CPU cycles on startup

This will not (yet?) push to Docker Hub, as this might not be the
best of all ideas after all. But it ensures the build doesn't fail
on changes to the sources.

Avoids unnecessary tries to push things when people develop in their
forked repos.

With defaulting to develop, we rest on using any build of the image during
experimentation etc to go with a (local) develop tag. Removing
the Java version from the tag makes it easier to use and reflects
the nature of it. It aligns image builds with the release schema
of the actual application while still allowing for experiments
and having different sources of truth for released and develop code.

- Make pushes to develop or master branch release a container image
  to Docker Hub by default (can be changed / extended).
- Defaulting to the develop tag by default makes it more reusable for
  depending workflows based on pull requests.
- Moving all multi-arch building to only happen on pushes,
  as it will be done during push/deploy phase only and those need
  credentials only avail in git push context running at repo owner of
  CI action.
- Removing the Java version matrix parameter, too - we are gonna stick
  with what is default for releasing the images as they are meant to
  be a somewhat reliable base. It's still open for experiments.

Instead of using "&& \" style continuation of a RUN layer,
newer Docker versions (since 2021) allow usage of heredocs.
Also move some ARG to more suitable places

By moving from tini to dumb-init, we can offer a new extension point:
if an application image extending this base image provides an executable
script at ${SCRIPT_DIR}/startInBackground.sh, it will be executed
after the init scripts and in parallel to the application server.

By adding ${SCRIPT_DIR} to $PATH, we can now also skip variable expansion,
fixing a bug: formerly, the "exec" in entrypoint.sh and startInForeground.sh
where not replacing the shell properly.

The switch to dumb-init makes sure signals will be transferred also to any
background processes!

To avoid unnecessary Shellspec runs for scripts that have no
such tests, branch out the Shellcheck part of it into different
workflow.

Also make "bash" explicit as the container base image using
an "unknown shebang" via dumb-init, but it's simply bash.

Adding notes about the image tags produced by the community
for reuse in the community. Document final tagging
strategy, using the branch name (develop/main) instead of
the Java version or sth.

Reshape the automated builds and publishing part to be included
in the supported tags and build instructions section to reduce
text complexity and group matching parts together.

Addin description on requirements to build cross platform
added as subsection of the build instructions seemed valuable.

Many scripts shipped with an app image might rely
on the availability of an external service, API or simply
the database or search index.

Adding a standard script here to make it easier to wait for
their availability.

With the merge of IQSS#8949 the custom version is no longer necessary.

The upgrade to 5.2022.3 made Dataverse deployments
fail because the postboot script deployment method
was broken. This has been fixed with 5.2022.4, which
is why we use this version now.

Should speed up recurring builds a bit.

- Instead of a /docroot, add a more generic /dv which is owned by payara:payara
  and can be used to either store data in a single volume using subfolders or
  use subfolders with different backing volumes. Anyway, data is not written
  to overlay FS this way. (As long as an app image points to this location)
- Also define /secrets and /dumps as volumes, so data flowing into these
  locations is again not added to the overlay FS (which might cause severe
  damage in case of heap dumps!)
- Document the different locations in the base image guide.
- Remove the /docroot workaround for uploaded files. This will be solved at application
  level (either by moving the workaround there) or IQSS#8983

Instead of only running the steps to push images to Docker Hub
on a Git push event, also make it possible to run them an anything
not being a pull_request event. (Like a schedule)

…8932

When pushing to Docker Hub from development, we now also push
a short description with disclaimers, links to docs and license hints.

Explain a bit (short!) what this image is and what to expect.

Github context offers ".ref" but we need ".ref_name" to
match *just* the branch name.

The login to the registry needs to be explicit
otherwise pushes will fail to acquire the
correct token and pushes are rejected with
"insufficient_scope: authorization failed"

Co-authored-by: Benjamin Peuch <benjamin.peuch@gmail.com>

Co-authored-by: Benjamin Peuch <benjamin.peuch@gmail.com>

Thanks @atrisovic @pdurbin

As requested by review from @pdurbin, aligning image tag names.