Java: Remove local query variants.

[michaelnebel]

In this PR we remove the local query variants.

The results from the queries can still be found by configuring threat models to also include local sources and using the non local query variants.

Some notes to consider in terms of review:

• Even though the java/tainted-numeric-cast is not completely similar to java/tainted-numeric-cast-local it appears that the difference in the where clause is coded into the sanitiser (but the local query variant was just not updated accordingly): Java: Move sink-constraints into the configuration in NumericCastTainted.ql. #10084
• The sanitiser for java/http-response-splitting is not identical to java/http-response-splitting-local, but it looks like a missing implementation detail on Java: Introduce a common sanitizer type for types which cannot realistically carry taint. #15291
• The sanitiser for java/unvalidated-url-redirection is not identical java/unvalidated-url-redirection-local, but it looks like a missing implementation detail on Java: Add extension point and default sanitizer to Open Redirect query #15565
• It looks a bit inconsistent in the auto model util library that it is only for the java/command-line-injection that both local and remote sources are included (maybe it is because both these data flow configurations are in the same QL lib, but this is not the case for the other local vs non local query modules).

I have not changed the java/tainted-permissions-check query. It is hardcoded to use UserInput as sources (both remote and local sources). Should it be considered to make this an threat model opt-in instead?

There are still some experimental queries where the exist a local and non local query variant.

Comments to the DCA experiment:
DCA was run on the nightly source suite and the security extended query suite and for variant v0 the threat model configuration was the default (remote sources) and for variant v1 the threat model configuration was set to remote and local.

• Performance drop of 7%. This looks acceptable. In variant v0 only remote sources are included and in in v1 both remote and local sources are included for queries that have opt'ed in to threat models.
• Approximately 7k extra alerts found.
• The only queries that showed a decrease in the number of alerts are: java/concatenated-command-line and java/concatenated-sql-query. This is not surprising as java/concatenated-command-line excludes all findings by java/command-line-injection (which shows an increase in findings) and java/concatenated-sql-query excludes all findings by java/sql-injection (which also shows an increase in findings).
• A similar experiment was run on Java: Enable threat models for most Java queries. #14370 where the quality of the results were checked (and that the combined sources found the combined results).

[github-actions]

QHelp previews:

[atorralba]

This is great, thank you! 🎉

[atorralba]

LGTM!

I have not changed the java/tainted-permissions-check query. It is hardcoded to use UserInput as sources (both remote and local sources). Should it be considered to make this an threat model opt-in instead?

The query is so old that it probably predated remote flow sources and the old UserInput class was used instead. So it probably would make sense to adapt it to threat models as well, but we can defer this decision and change it in another PR if you want.

Since this change is pretty impactful, maybe we should coordinate communication with @coadaflorin before merging/releasing.

[michaelnebel]

@atorralba : Thank you for the review (and I agree with your comment)

@coadaflorin : Last year we discussed the removal of local versions of the security queries. Now that threat models has been properly released and public documentation is available for enabling (the local) threat models, it makes (in my opinion) that we delete the local variants. Is that acceptable from a product perspective?

[coadaflorin]

We already announced when we released C# threat models that for some queries we removed the local sources, so I think it's fair that we follow-up with this work.

If someone manually included this query in their suite, what would they see?