Stable Config file: target system properties in process_arguments and support template variables in YamlParser

[mtoffl01]

What Does This Do

This PR adds support for matching system property keys in the Stable Configuration selector, even when those properties include values. For example, a selector with -Darg1 will now correctly match a Java process started with -Darg1=value.

It also introduces support for template variables in the Stable Configuration file schema. These variables can resolve values from process arguments and environment variables. (See reference for more details.)

Notes & Limitations:

Scope Limitation: This change restricts process_arguments selectors and template variables to System Properties only.
Required Format: System Properties must be referenced using their full -D prefix, without specifying a value (e.g., use -Dkey, not key nor -Dkey=value).

Motivation

Stable Config users must be able to target services based on the presence of a specific System Property, regardless of its value. For instance, -Darg1 should match any process started with -Darg1=abcd, -Darg1=xyz, etc.

Currently, our only known use case for process_arguments selectors involves System Properties. If a need arises to support additional types of JVM arguments in the future, we can revisit and expand this functionality.

Additional Notes

Contributor Checklist

• Format the title according the contribution guidelines
• Assign the type: and (comp: or inst:) labels in addition to any usefull labels
• Don't use close, fix or any linking keywords when referencing an issue.
  Use solves instead, and assign the PR milestone to the issue
• Update the public documentation in case of new configuration flag or behavior

Jira ticket: [PROJ-IDENT]

[pr-commenter]

Benchmarks

Startup

Load

Dacapo

[github-actions]

Hi! 👋 Thanks for your pull request! 🎉

To help us review it, please make sure to:

• Add at least one type, and one component or instrumentation label to the pull request

If you need help, please check our contributing guidelines.

[PerfectSlayer]

Hey @mtoffl01

I feel there is a mix of concerns about how the CLIHelper changed.
As it’s a common composent, we would expect him to keep providing the JVM arguments. (-Dkey=value being a process argument in itself after all)

While I think that parsing JVM properties is interesting (and needed), it should not replace the process arguments API.
So what about having:

• one way to retrieve arguments as a list of string (as before)
• one way of querying JVM properties (get the key value if any)
• but still do the parsing in one pass

Overall, I also think the common component needs:

• A complete Javadoc to define its expected capability / behavior,
• Some tests in order to check edge case behavior (like property redefinition, empty property value, etc...).
  What do you thing about it?

And my mid-term goal is to make this component evolves to a system / env component that will be provide any kind of information about the execution context (JDK version, vendor, native-image, etc...).

[mcculls]

One question - will users ever want to substitute a variable with an empty string?

Currently we don't support this, because the variable will be replaced with UNDEFINED - but a user might want to have some kind of optional variable that may have a value or optionally be the empty string...

[mtoffl01]

Addressing in a separate PR: #8759

[mcculls]

LGTM, just a question about whether we should allow users to set variables to the empty string or not

[PerfectSlayer]

I would avoid creating one-liner helpers in internal-api.
They can be replaced by their equivalent static method calls from JDK.

[PerfectSlayer]

Is that useful to create a dedicated method for a single call which can already be written: Files.write(path, data.getBytes())?
Default open options looks good enough for the testing, aren't they?
And I would not recommend re-using this method as it hide the encoding / charset to used (which is usually not recommended).

[PerfectSlayer]

Similarly, this is one-liner helper.
Checking the exception is not required is groovy so you can directly write Files.createTempFile() in your test, and the exception handling won't be useful as you will certainly end up with another exception (NullPoienterException) if something fails.

Additionally, Spock and test framework usually provide tools for temporary files (for example @TempDir for Spock: https://spockframework.org/spock/docs/2.3/all_in_one.html#_temp_dir)