trait_selection: Restore type-op solver constraints

[Dnreikronos]

Bringing back #161423 after @BoxyUwU suggested checking perf again now that Khy's lazy constraint storage from #162531 has landed. The original fix was reverted because of the performance regression.

With assumptions on binders enabled, proving a predicate or normalizing a type can produce solver region constraints inside a canonical query. Those constraints weren't included in the response, so they disappeared when the query's inference context went away. Borrowck could then accept a body with a missing lifetime bound, as in borrowck_env_fail.

The solver constraints now travel in QueryRegionConstraints and get instantiated along with the rest of the response. scrape_region_constraints also drains constraints from completed operations into that same result. Borrowck collects them and lowers them once the body's bounds are available. Constraints from normalizing implied bounds also reach lexical regionck. The cached constraints have no spans, so each caller supplies its own.

I think keeping the constraints in the query response is the right place for this. It keeps the existing query cache and fast paths working, and gives the constraints the same route back to the caller as the other query results. The payload stays optional, so we don't allocate an empty solver constraint tree when AoB is off. I still want a fresh perf run before landing it, since avoiding those allocations alone doesn't tell us what the overall cost is.

The compiler check passed locally, along with the alias-outlives regression, the pass test in default, next-solver and AoB modes, and the three solver-constraint unit tests. Tidy and formatting checks passed too.

r? @BoxyUwU

[rustbot]

Some changes occurred to the core trait solver

cc @rust-lang/initiative-trait-system-refactor

[BoxyUwU]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 081f5df (081f5df2a6df38b659cfe0e213131198dda25b5e)
Base parent: 8d1a764 (8d1a76430406c877b35d0b627e7f796dcf0dfeca)

[rust-timer]

Finished benchmarking commit (081f5df): comparison URL.

Overall result: ❌ regressions - please read:

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

@bors rollup=never rustc-perf
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	0.2%	[0.1%, 0.3%]	40
Regressions ❌ (secondary)	0.2%	[0.0%, 0.3%]	22
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.2%	[0.1%, 0.3%]	40

Max RSS (memory usage)

Results (primary 2.1%, secondary 2.6%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.1%	[2.1%, 2.1%]	1
Regressions ❌ (secondary)	2.6%	[2.6%, 2.6%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.1%	[2.1%, 2.1%]	1

Cycles

Results (secondary 4.3%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	4.3%	[4.3%, 4.3%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 489.893s -> 488.402s (-0.30%)
Artifact size: 408.60 MiB -> 408.71 MiB (0.03%)

[BoxyUwU]

that is significantly better than last time :3 though still subopties