[Task] Port Rules engine from Nashorn to GraalVM JS

[andrewazores]

Related to #274 - when ported to Quarkus, Nashorn should definitely be dropped in favour of Graal/Mandrel's implementation. Can the downstream product depend on the GraalVM impl below?

Nashorn was already deprecated in JDK11 and has been fully removed from the main JDK in more recent releases. There is still a separate upstream https://github.com/openjdk/nashorn project that we can pull in as a replacement dependency, but it would probably be even better to switch to GraalVM's JS implementation.

https://www.graalvm.org/22.1/reference-manual/js/NashornMigrationGuide/

https://www.graalvm.org/22.1/reference-manual/js/RunOnJDK/

[andrewazores]

Here is an interesting alternative:

https://github.com/google/cel-spec
https://github.com/google/cel-java

From the outset, using a parser-restricted JavaScript subset for the matchExpressions was always a compromise between ease of use for the user (syntactical similarity to Java, which Cryostat users are probably familiar with), minimal implementation effort and maintenance overhead (much less work and code than implementing a small language ourselves), and security/performance (clients should not be able to submit arbitrary expressions that are Turing-complete and cause arbitrary execution on the server).

The Common Expression Language meets these goals by having a very similar and familiar syntax, having a small and non-Turing-complete language, and having a Java implementation that we can mostly plug-and-play on the Cryostat server.

This is unlikely to be 100% syntax compatible with existing JavaScript-based matchExpressions, so changing the implementation in this way should be held for a major version.

[andrewazores]

Closing. 3.0 now uses Project Nessie cel-java, not a JavaScript engine.