Python: enable diff-informed data flow queries

[asgerf]

The first commit is an auto-generated patch that enables diff-informed data flow in the obvious cases, and inserts a TODO comment in the non-obvious cases. Later commits fix up the TODOs.

Unavoidable test failure in --check-diff-informed

Diff-informedness can be tested with codeql test run --check-diff-informed (not currently run by CI).

Note that this PR is currently observing a test failure from --check-diff-informed due to this situation in the PartialServerSideRequestForgery test case:

conn = HTTPConnection(unsafe_host) # <-- 'unsafe_host' is the sink
conn.request("GET", unsafe_path) # <-- related location inside the diff, causes the sink to be active
conn.request("GET", "/foo") # <-- outside the diff, test fails due to this being wrongly included

At the moment there is no way to satisfy the test runner without relying on AlertFiltering directly or outright disabling diff-informedness for that query. I believe the plan is to fix this on the CLI side, in which case we should be able to keep the PartialServerSideRequestForgery query diff-informed. (See internal discussion)

Copilot reviewed 54 out of 54 changed files in this pull request and generated no comments.

Tip: Copilot only keeps its highest confidence comments to reduce noise and keep you focused. Learn more

[adityasharad]

Looks reasonable, I appreciate the inline comments about the exceptional cases.

[adityasharad]

Optional thought: This pattern makes me think we should allow the custom Sink classes to expose a getASelectedLocation predicate and expand it through overrides, then just call result = sink.(Sink).getASelectedLocation() here. Not necessary to figure out for this PR.

[asgerf]

The pattern I have in mind is that the select clause must only select entities that are returned from a member predicate on the Source and Sink classes, and then those same predicates must be mentioned in the config. This can be enforced with a QL4QL query without needing too much static analysis.

The problem with putting a getASelectedLocation member on Sink is that it must still be implemented far away from the select clause. It doesn't avoid the strong coupling between two things that are far apart.