Split up jvm.options for interoperability

[lyind]

Description

Make OpenSearch more container-friendly by splitting out default heap sizing from other, more specific JVM options.

This allows replacing or removing certain parts of the jvm.options without touching areas that are highly specific to OpenSearch (e.g. workarounds, logging and GC configuration).

Example use case:

Vertically scaling a deployment on Kubernetes includes modifying spec.containers[].resources.limits.memory, but that either leads to out-of-memory errors (OOMKilled) or the OpenSearch pod not making use of the additional memory, if OPENSEARCH_JAVA_OPTS isn't modified in parallel.

Making use of the JVM's container awareness (-XX:+UseContainerSupport) to scale the heap dynamically isn't possible, due to static defaults in jvm.options, which conflict with automatic heap sizing.

While it's trivial to mount files (i.e. heap.options) into the OpenSearch container at a certain location, one would rather not touch most parts of the configuration, thus this PR.

Related Issues

Check List

• Functionality includes testing.
• API changes companion pull request created, if applicable.
• Public documentation issue/PR created, if applicable.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[github-actions]

❌ Gradle check result for 722bd79:

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?