[red-knot] Improve handling of visibility constraints in external modules when resolving * imports

[AlexWaygood]

Summary

Further work towards #14169.

This adjusts our handling of * imports so that we pay attention to visibility constraints in the external module (the module symbols are being imported from) when we infer the boundness of symbols defined via a * import. I.e., for something like this:

```toml
python-version = "3.9"
```

`a.py`:

```py
import sys

if sys.version_info >= (3, 10):
    X = True
```

`b.py`:

```py
from a import *

print(X)
```

We will now correctly emit an [unresolved-reference] diagnostic on the use of X in b.py: the visibility constraints in a.py resolve to Truthiness::AlwaysFalse, so no symbols are actually bound in b.py as a result of the * import.

Implementation

When adding each *-import definition to the UseDefMap, we snapshot the SymbolState as it was prior to the * import definition (possibly) overriding any (possible) previous definitions. Then, in symbol::symbol_from_bindings_impl, we evaluate * import definitions to determine the boundness of the symbol in the external module. If the symbol is in fact unbound in the external module (due to visibility constraints resolving to Truthiness::AlwaysFalse), we determine that the * import did not in fact provide an additional binding for this symbol, and in the importing module we fall back to the SymbolState for that symbol prior to the *-import definition.

In order to be able to resolve * imports from symbol.rs as well as from types/infer.rs, several functions are pulled out of infer.rs into a new import_resolution module where they can be accessed from both types/infer.rs and symbol.rs.

Problems with this approach

This approach works well for symbols in the external module that are statically known to either be definitely bound or definitely unbound. But the logic in symbol.rs is still somewhat naive, and doesn't work for possibly-unbound definitions in the external module. I've added a failing test in this PR to illustrate the issue: I don't know how to fix it properly, and would welcome ideas. In addition to the new failing test, the PR does not address any of these TODOs, and ideally it would:

ruff/crates/red_knot_python_semantic/resources/mdtest/import/star.md

Lines 217 to 227 in 761749c

	M, # TODO: could emit diagnostic about being possibly unbound
	N, # TODO: could emit diagnostic about being possibly unbound
	O, # TODO: could emit diagnostic about being possibly unbound
	P, # TODO: could emit diagnostic about being possibly unbound
	Q, # TODO: could emit diagnostic about being possibly unbound
	R, # TODO: could emit diagnostic about being possibly unbound
	S, # TODO: could emit diagnostic about being possibly unbound
	T, # TODO: could emit diagnostic about being possibly unbound
	U, # TODO: could emit diagnostic about being possibly unbound
	V, # TODO: could emit diagnostic about being possibly unbound
	W, # TODO: could emit diagnostic about being possibly unbound

Test Plan

Existing assertions in mdtests updated; new ones added.

[github-actions]

mypy_primer results

No ecosystem changes detected ✅

[carljm]

This is looking pretty good! Didn't do a full review, just commented on the main open issues I saw.

[AlexWaygood]

Quite apart from any of the big things I was stuck on (thank you all for your review comments!), I realised after sleeping on it that I could significantly simplify things by reviving the idea I had previously in #16923 (comment). There's now no need for moving any logic from infer.rs into a new import_resolution submodule, and all the questions about "Where do we do tracing?" are now redundant 🥳

[codspeed-hq]

CodSpeed Performance Report

Merging #17286 will degrade performances by 12.49%

_{Comparing alex/star-statically-known-2 (9415521) with main (f1ba596)}

Summary

❌ 1 regressions
✅ 31 untouched benchmarks

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

	Benchmark	BASE	HEAD	Change
❌	red_knot_check_file[cold]	96.7 ms	110.5 ms	-12.49%

[AlexWaygood]

I tried out @sharkdp's suggested alternative implementation, and it appears to work beautifully... except that this PR is now triggering(?) a Salsa panic in some unrelated tests in a file I didn't touch:

  crates/red_knot_python_semantic/resources/mdtest/properties.md:203 panicked at /home/runner/.cargo/git/checkouts/salsa-e6f3bb7c2a062968/296a8c7/src/tracked_struct.rs:832:21
  crates/red_knot_python_semantic/resources/mdtest/properties.md:203 access to field whilst the value is being initialized

which looks like the same Salsa panic that @dcreager was running into in #17023 before he applied ea12548 to that PR...

[AlexWaygood]

All changes to this file are just commenting out the test that causes the Salsa panic (I just applied @dcreager's commit ea12548 to this branch 😆)

[carljm]

This is so nice and clean now! Love it.

I think given our upcoming deadlines I would be inclined to merge this even with a significant regression (especially if that regression gets smaller percentage-wise when we check a larger codebase), and prefer to have someone spend dedicated time later looking for performance wins. But it wouldn't hurt to at least look at some profiles (the CodSpeed ones are sadly useless, so they have to be generated locally) to understand which queries we spend more time in now.

[sharkdp]

Very nice — Thank you!

[AlexWaygood]

Merging #17286 will degrade performances by 12.49%

We discussed this internally. It's obviously far from ideal, but for now we're going to eat the performance regression. We have some ideas for how to address it, but they may or may not work out, and we want to move onto other tasks for now. I'll writeup a separate issue with our findings from looking at the tracing logs and various profiles.