This implements support for test extraction by two mechanisms:
* In autobuild mode, setting `CODEQL_EXTRACTOR_GO_EXTRACT_TESTS` to `true`.
* In manual build mode, tracing a `go test` command (`go test -c` is to be recommended for efficiency).
Go deals with test compilation by creating several extra packages on top of those expected from inspection of the source code (see docs of `packages.Load` for more detail): packages whose IDs include a suffix like `mydomain.com/mypackage [mydomain.com/mypackage.test]`, and packages containing generated test driver code like `mydomain.com/mypackage.test`. There are also additional packages like `mydomain.com/mypackage_tests` which are explicitly present in source code, but not compiled by a normal `go build`.
So far as I can tell, the purpose of the two variants of the package is to resolve dependency cycles (because the tests variant of the package can have more dependencies than the non-tests variant, and non-test code can compile against non-test package variants). Since the test package variants seems to be a superset of the non-tests variant, I employ the simple heuristic of ignoring the variant of each package with the shortest ID. I haven't seen a case where there are three or more variants of a package, so I expect this to always identify the tests variant as the preferred one. If several variants were extracted, and we were to attempt to match Golang's linkage strategy among the different variants, we would need to extend trap-file name and most top-level symbol trap IDs with the package variant they come from; I hope this won't prove necessary.
"Real" `_tests` packages, and wholly synthetic driver code packages, are extracted just like normal.
As part of adding support for threat-models to Python/JS (see
https://github.com/github/codeql/pull/17203), we ran into some trouble
with name clashes.
Naming in existing languages supporting threat-models:
- `SourceNode` (for QL only modeling)
- `ThreatModelFlowSource` (for active sources from QL or data-extensions)
However, since we use `LocalSourceNode` in Python, and `SourceNode` in
JS (for local source nodes), it seems a bit confusing to follow the same
naming convention as other languages, and we had to come up with new names.
Initially I used `ThreatModelSource` for the "QL only modeling", but
that meant that we needed a new name to represent the active sources
coming from either QL or data-extensions... for this I came up with
`ActiveThreatModelSource`, and I really liked it. To me, it's much
clearer that this class only contains the currently active threat
model sources.
So to align languages, I got approval from @michaelnebel to rename the
existing classes.
