Always make progress on FnOnce ClosureKind goals in the old solver

[compiler-errors]

All closures always implement FnOnce. IDK if this is worthwhile, but it does mean goals get flushed sooner.

@bors try @rust-timer queue

r? @jackh726

(rustbot has picked a reviewer for you, use r? to override)

⌛ Trying commit 0e9241c with merge cfc4c29...

☀️ Try build successful - checks-actions
Build commit: cfc4c29 (cfc4c2907b9db6c69489a87b40f4b1b2d103e1b3)

Do these predicates ever result in the InferCtxt being changed in any way? What's stopping us from moving this check before the closure_kind call?

Finished benchmarking commit (cfc4c29): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

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

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.3%	[0.3%, 0.3%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.2%	[-4.5%, -3.9%]	6
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

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

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 677.57s -> 677.207s (-0.05%)
Artifact size: 313.75 MiB -> 313.81 MiB (0.02%)

Do these predicates ever result in the InferCtxt being changed in any way? What's stopping us from moving this check before the closure_kind call?

No, they never have side-effects. We could move the check sooner if we wanted to.

However, this PR is somewhat superseded by #118120, which takes a somewhat opposite angle by just outright removing the ClosureKind predicate from the language. I hope that that PR doesn't negatively affect any test suites, since I prefer it greatly.

Well, #118120 is not a regression, so this PR can be superseded.