Create jvm options dsl and generator in gradle

[rjernst]

Elasticsearch has a text file called jvm.options which is pretty much a line delimited set of additional command line arguments for java when invoked by bin/elasticsearch (with the caveat it has version specific conditionals to allow eg java 9 specific options). While the integration tests, by virtue of running bin/elasticsearch, use these options, the unit tests do not. This issue is intended to outline a proposal for how unit tests can use these options, without the need for duplication across gradle and the jvm.options text file.

The proposal is to move the specification of the jvm options we ship with into gradle itself. That would allow the unit tests to consume the dsl (or rather, the dsl can fan it's configured settings out to all RandomizedTestTasks or something like that), and the shipped jvm.options file can be generated from the dsl as part of the distribution build.

[elasticmachine]

Pinging @elastic/es-core-infra

[alpar-t]

@rjernst what is the advantage of the DSL vs reading the file and passing in the arguments for the tests ? We could expose it trough a configuration on the relevant project and make it a proper dependency if you are concerned about locating it.

[rjernst]

The file has a syntax that is not simple to read (we have our own parser so we can have options specific to a java version). Since we need this at gradle configuration time, we would have a chicken/egg problem because to reuse that parser would mean already having compiled the parser.

[pgomulka]

this issue should also be taken into account #48222

[cbuescher]

Also related: #46118 (comment)

[mark-vieira]

I think this is even less compelling with the addition of auto heap sizing so we've reduced the need for folks to touch the jvm.options file at all by a significant amount. I'm going to close this issue unless a testing scenario that would benefit from such a thing comes up again.