CI: Add CodeQL workflow for code scanning

[pniedzielski]

This repository’s CodeQL analysis had been running under GitHub’s Default setup, which worked fine for the actions and python languages, since neither needs a build. It never analyzed our pure C++ layer, though: this repository wraps libbmq in hand-written C++ under src/cpp (pybmq::Session and friends), which the pure Python layer under src/blazingmq reaches through a thin Cython glue layer (_ext.pyx). Default setup’s autobuilder has no way to know that building any of this requires first building BlazingMQ itself as a dependency, so c-cpp analysis was silently producing nothing.

This patch adds codeql.yaml, an advanced (workflow-based) CodeQL configuration that takes over analysis for all three languages. For the three languages, we make two jobs:

1. For GitHub Actions and for Python, the workflow includes a analyze-light job that replicates the default setup, as these languages continue to need no build.

2. For C++, this workflow builds the extension module before running CodeQL against it. In order to do so, this workflow reuses the same “build BlazingMQ as a dependency” job that build.yaml uses, kept identical (including its cache key) so the two workflows share one set of cached build artifacts, then builds the extension module before running CodeQL against it.

   The resulting database necessarily includes Cython-generated C++ code as well as the vendored BDE/NTF/BlazingMQ headers pulled in from the dependency build, so to avoid false findings from the dependencies, or from generated Cython code we can do little about, this patch strips out alerts from code not located in src/cpp using jq. This trick is a little hacky, but the alternatives don’t really get us what we want. CodeQL does provide a paths-ignore config option, which we could use to ignore _ext.cpp, but this only takes effect when using build-mode: none. However, that would prevent CodeQL from resolving BDE and BlazingMQ types (bdlbb::Blob, bmqa::Message, …) that comprise most of the surface area of src/cpp code, making the static analysis less than useful. The cleanest thing to do is to build everything, and then filter out the findings that are not relevant to us.

GitHub does not allow a Default and an advanced setup to run side by side, even for different languages, so landing this patch also requires disabling this repository’s Default CodeQL setup.

[pniedzielski]

Hm... to test this, we need to disable the default codeql workflow...

[pniedzielski]

Swapped to the CodeQL advanced configuration. Unfortunately, this turns off CodeQL on main too, until this is merged.

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.