This is partly motivated by the MaD tests which looks much better now in
my opinion.
I also wanted this for testing argument passing. In Python we're
adopting the same argument positions as Ruby has
[here](4f3751dfea/ruby/ql/lib/codeql/ruby/dataflow/internal/DataFlowDispatch.qll (L508-L540))
So it would be nice if `arg[keyword foo]=...` was allowed, without
having to transform the `toString()` result of an argument position into
something without a space.
This enables us to keep the framework modeling tests under `/frameworks`
folder
I had hoped to use `mad-sink[<kind>]` syntax, but that was not allowed
:(
Maybe it oculd be allowed in the future, but for now I'll stick with the
more ugly solution of `mad-sink__<kind>`
I had to rewrite the SINK1-SINK7 definitions, since this new requirement
complained that we had to add this `MISSING: flow` annotation :D
Doing this implementation also revealed that there was a bug, since I
did not compare files when checking for these `MISSING:` annotations. So
fixed that up in the implementation for inline taint tests as well.
(extra whitespace in argumentPassing.py to avoid changing line numbers
for other tests)
- also update `validTest.py`, but commented out for now
otherwise CI will fail until we force it to run with Python 3.10
- added debug utility for dataflow (`dataflowTestPaths.ql`)
I think `getUrl` is a bit too misleading, since from the name, I would
only ever expect ONE result for one request being made.
`getAUrlPart` captures that there could be multiple results, and that
they might not constitute a whole URl.
Which is the same naming I used when I tried to model this a long time ago
a80860cdc6/python/ql/lib/semmle/python/web/Http.qll (L102-L111)
Also adjusts test slightly. Writing
`clientRequestDisablesCertValidation=False` to mean that certificate
validation was disabled by the `False` expression is just confusing, as
it easily reads as _certificate validate was NOT disabled_ :|
The new one ties to each request that is being made, which seems like
the right setup.
For the snippet below, our current query is able to show _why_ we
consider `var` to be a falsey value that would disable SSL/TLS
verification. I'm not sure we're going to need the part that Ruby did,
for being able to specify _where_ the verification was removed, but
we'll see.
```
requests.get(url, verify=var)
```
Taken from Ruby, except that `getURL` member predicate was changed to
`getUrl` to keep consistency with the rest of our concepts, and stick
to our naming convention.
