I guess we could have done this at the very start of introducing this
test in this PR, but I think the last commit was mostly inspired from
looking at all the things that evidently was re-exported from the trace
import, even when I knew they were not available because of the
`__all__` definition.
However, we can see that `from <pkg> import *` and `import pkg` are
handled differently. Would have liked `has_defined_all_indirection` to
behave in the same way no matter how the import was made.
Notice that `has_defined_all_indirection` all have both
`all_defined_bar_copy` and `all_defined_foo_copy` marked as exported,
even though only `all_defined_foo_copy` is available.
For `from <pkg> import <attr>` we would use to treat the `<pkg>`
(ImportExpr) as a definition of the name `<attr>`.
Since this removes bad import-flow, and nothing broke, I'm guessing this
was never intentional.
However, as illustrated by the `CWE-327-InsecureProtocol` test, this fix
is NOT good enough, since now even the `secure_context` is considered to
be insecure (for both versions). Ouch.
Will fix this in a later commit, since it was only discoverd late on.
Similar to the Ruby changes from
https://github.com/github/codeql/pull/11461
I feel the change to `DataFlowFunciton.getParameter` where we use
`not exists(func.getArgByName(_))` is not very great, but I was not allowed
to use `not exists(this.getParameter(any(ParameterPosition _).isKeyword(_)))`
because of negative recursion.
validTest.py did not pass, since we use `SINK3_F`.
I initially tried swapping the order
```
args = (arg1, arg2) # $ arg1 arg2 func=starargs_only
more_args = (arg4, arg3)
starargs_only(*args, *more_args)
```
But then asked myself, what is it _actually_ we're testing here? and it
seems to be the way we handle multiple *args arguments in the same call,
so I converted the test to be that instead! (and it matches what we do
in test_stararg_mixed)
