Java: Promote MVEL injection query from experimental - #6001

⚠️ The head of this PR and the base branch were compared for differences in the framework coverage reports. The generated reports are available in the artifacts of this workflow run. The differences will be picked up by the nightly job after the PR gets merged. The differences can be found in the comparison artifact of this workflow run.

I'd like some reshuffling of the content of the two files MvelInjectionQuery.qll and MvelInjectionSinkModels.qll. Only the configuration should go in MvelInjectionQuery.qll whereas the rest of it should go in a file called MvelInjection.qll, which can then both expose the extension points and be generally importable without leaking the configuration.

I was following the pattern applied to JEXL Injection in all my open PRs:

• https://github.com/github/codeql/blob/6823855e9cac61a72b934a2b8b1f99b246d656f1/java/ql/src/semmle/code/java/security/JexlInjectionSinkModels.qll
• https://github.com/github/codeql/blob/6823855e9cac61a72b934a2b8b1f99b246d656f1/java/ql/src/semmle/code/java/security/JexlInjectionQuery.qll

Should that be changed everywhere to *Query.qll containing only the configuration, and *.qll (instead of *SinkModels.qll) containing everything else and being imported in ExternalFlow.qll? See 70081b6 to check if it fits the expectations.

There are also some queries that use a secondary data flow configuration (e.g. DataFlow2). With these changes, should those be made public and moved to *Query.qll too?

There is some potential merit in keeping the sink models separate such that ExternalFlow doesn't need to import a lot of unrelated things - if we do that then we likely need 3 supporting qll files rather than 2, since all the extension points for the query shouldn't be in *Query.qll, but rather in something more generally importable. But I think the structure I outlined and which is current in this PR is also fine. Splitting the sinks into a third file doesn't really make much difference (the only potential difference might be compilation time). So yeah, the JEXL example should be refactored as well - we don't want the query extension points in a *Query.qll file. @smowton what do you think? Do you have a preference for 2 or 3 supporting qll files for this case?

⚠️ The head of this PR and the base branch were compared for differences in the framework coverage reports. The generated reports are available in the artifacts of this workflow run. The differences will be picked up by the nightly job after the PR gets merged. The differences can be found in the comparison artifact of this workflow run.

@atorralba - this is looking good to me ✨
I made a few minor tweaks to the qhelp file and noticed powerfull on line 23. Not sure whether this is a typo or a genuine context name, so left it as is for now.
Hope this helps!

Thank you for the review! It was a typo indeed. I removed the word altogether since it wasn't too relevant, and added a "GOOD" example to the sample Java code.