Implement threat models as extension packs

[dbartol]

This PR allows users to configure the threat models for their analysis by representing each threat model as an extension pack that can be added to the analysis. For example, if a user wanted to enable the "local flow sources" threat model, they would run codeql database analyze --extensionPack codeql/threat-local, or the Actions or VS Code equivalent. This avoids having to add a new configuration option in many different places.

Implementation notes

I moved the existing ExternalFlowConfiguration.qll file from Java into its own library pack, codeql/threat-models. This pack is language-agnostic. Any language that wants to consume threat models will depend on this pack, and every threat model extension pack will target this pack for extension.

For each of the high-level threat models currently supported, I added a new extension pack codeql/threat-<name>, where <name> is the name of the threat model. This extension pack just adds a single row to the supportedThreatModels predicate from codeql/threat-models, specifying the name of the threat model.

The threat model system in QL supports a hierarchy of threat models (for example, "files" and "environment" are both sub-threat-models of "local"). I haven't added extension packs for the low-level threat models yet, but we can add those later easily enough.

[michaelnebel]

This looks good!
IMO it is great idea to share this between the different languages as it will help drive the re-use of existing threat model kinds/groups.

As a part of this PR we probably need to add an extension pack for the threat model "all" (it is not explicitly listed in the hierarcy, but if this is used then all sources will be included).

You also mention in the description, we probably need to add extension packs for the "low level" kinds as well (if these are not needed it might be an indication that the threat model kind/grouping are to granular).

It requires a bit more boiler plate code to introduce a new source or group with this design - I don't think that is a problem as we don't have that many source kinds as it is (at least not for java or C#) - but maybe it is worth checking with language teams in general whether this is a problem (either now or in the known future). However, if we are to do something similar for sink kinds then it will look differently as they are more of those and it appears that new ones are more frequently introduced.

Furthermore, what happens if we introduce tens or hundreds of extension packs in this way?

[aeisenberg]

Nice. I think this is generally the best approach.

[aeisenberg]

I guess we just need to assume that having one threat model grouping will not have any conflicts across languages. At some point, we may want to move some of these lines into library packs themselves.

[dbartol]

To be clear, this PR was marked as "merged" because #14582 was merged, and that PR was based on the commits from this PR. The actual extension packs were removed before that PR was merged.