only rerun const eval in next-solver if the const actually references opaques

[sjwang05]

Split off from #161274: #161274 (comment)

Previously, we would unconditionally rerun eval if we were in ErasedNotCoherence mode, even if the const's eval result wouldn't depend on the TypingMode. This caused a slowdown with large types whose nested goals contained normalization goals involving types with anon assoc consts, since normalizing needs to evaluate those consts, which can't be done in ErasedNotCoherence mode, causing those goals, and all their parent goals, to be reevaluated.

For instance, if we had a large tuple with N elements in a goal, and each of the N elements had such a normalization goal, this would cause us to go quadratic, as is the case here: rust-lang/trait-system-refactor-initiative#272 (comment)

With this PR, we only retry const eval if the const's generics actually depend on any opaques which ErasedNotCoherence would influence. We also bail if gce is enabled, since not doing so causes us to ICE.

next-solver is still 5x-ish slower than old solver on rust-lang/trait-system-refactor-initiative#272 (comment) due to some other ✨ Hidden Quadratics somewhere, but this PR improves perf on that specific reproducer by about 3x.

cc @lcnr, @jdonszelmann

[rustbot]

r? @Enselic

rustbot has assigned @Enselic.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 75 candidates
• Random selection from 18 candidates

[Enselic]

r? lcnr since you were the one that requested a separate PR for this.

[lcnr]

r? jdonszelmann

[rustbot]

jdonszelmann is currently at their maximum review capacity.
They may take a while to respond.

[jdonszelmann]

I think this pr has a soft conflict with the renames in #162126. r=me,khyperia once resolved