Java: Threat model implementation with priorities.

[dbartol]

This is an alternate implementation of threat models that depends on a new CLI option (--threat-model) that generates a temporary extension pack to configure the supported threat models. Compare to #14548, which does not require a new CLI option.

This implementation has a few advantages over the other:

• It allows disabling of a threat model that was enabled earlier in the configuration. This is useful for multi-level configuration scenarios where the org-level configuration specifies a particular threat model, but the repo-level configuration wants to disable it. It also helps within a single configuration when trying to enable all of the threat models in a group except for one particular one (e.g., all local sources except environment).
• It allows disabling of the default threat model via the same mechanism as disabling any other threat model.
• The all threat model works as originally intended.

The downside is that we have to add a new configuration setting to half a dozen places.

Implementation details

codeql database analyze will accept a new --threat-model option that can be specified multiple times. Each instance of the option accepts a string argument with the name of a threat model, optionally preceded by !. Without a !, the option enables the specified threat model, or, if the specified model is a group, all of its descendants. With a !, the option disables the specified threat model or its descendants. The options are processed in order.

Before running the analysis, the CLI will generate a temporary extension pack that extends the threatModelConfiguration predicate with one row for each instance of the --threat-model option. The row will contain the following columns:

• kind - The name of the threat model, without any ! prefix.
• enabled - A boolean value set to false if the argument had a ! prefix, and true, otherwise.
• priority - An int value specifying the order in which the option was processed. The first instance gets priority 0, the next gets priority 1, and so on.

At evaluation time, the codeql/threat-models library processes the threatModelConfiguration table to determine which threat models are actually enabled.

[michaelnebel]

This looks really nice @dbartol!
I have taken the liberty to update existing tests and add an extra one for the "subtraction".

[dbartol]

I have taken the liberty to update existing tests and add an extra one for the "subtraction".

Oh, cool, I was going to ask if we had a way for QL tests to specify data extensions, but I guess the answer is "yes".

[michaelnebel]

Really good! 👍
Lets also
(1) Get a review from someone on the java team.
(2) Run DCA (I will trigger an execution).

[aschackmull]

Some minor comments, otherwise LGTM!

[michaelnebel]

LGTM 👍
Will re-run DCA.

[michaelnebel]

DCA also looks good
(1) There are no changes to alerts
(2) There doesn't appear to be any performance regressions.

@dbartol : This PR can be merged now.