Disable projection sub-obligation optimization in intercrate mode

[Aaron1011]

The meaning of an 'evaluation' in intercrate mode is more complicated
than with an normal SelectionContext. To avoid potential issues,
we now always preserve all projection sub-obligations when in
intercrate mode. This avoids needing to answer whether or not
EvaluatedToOk always means the same thing in intercrate mode
as it does normally.

[rust-highfive]

r? @cjgillot

(rust-highfive has picked a reviewer for you, use r? to override)

[Aaron1011]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit da0816c with merge 0ad7c9beddfdc2e5f0aeb5f7ae7d796dd89173f7...

[bors]

☀️ Try build successful - checks-actions
Build commit: 0ad7c9beddfdc2e5f0aeb5f7ae7d796dd89173f7 (0ad7c9beddfdc2e5f0aeb5f7ae7d796dd89173f7)

[rust-timer]

Queued 0ad7c9beddfdc2e5f0aeb5f7ae7d796dd89173f7 with parent 2c7bc5e, future comparison URL.

[rust-timer]

Finished benchmarking commit (0ad7c9beddfdc2e5f0aeb5f7ae7d796dd89173f7): comparison url.

Summary: This benchmark run did not return any relevant changes.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

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 led to changes in compiler perf.

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

[cjgillot]

#88994 (comment)

The other PR (#88993) is less "obviously correct" and imo "more complicated" (though not really).

r? @rust-lang/traits

[lqd]

IIRC this was an alternative to #88994, and can thus probably be closed, right @Aaron1011 ?

[jackh726]

Closing since #88994 was merged.