fix: Cleanup provisional cycle head memos when query panics

[MichaReiser]

We've seen in astral-sh/ruff#20477 that Salsa can hang (it gets stuck in a fetch_with_retry and Memo::retry_provisional cycle) if a cycle head query panics.

I invested some time to see if there's an easy way to identify a Memo of a panicked query, but without success. That's why I decided to explore if we can clean up any provisional memo if a cycle head panics, and that turns out to be much easier.

/// Replaces any inserted memo with a fixpoint initial memo without a value if the current thread panics.
///
/// A regular query doesn't insert any memo if it panics and the query
/// simply gets re-executed if any later called query depends on the panicked query (and will panic again unless the query isn't deterministic).
///
/// Unfortunately, this isn't the case for cycle heads because Salsa first inserts the fixpoint initial memo and later inserts
/// provisional memos for every iteration. Detecting whether a query has previously panicked
/// in `fetch` (e.g., `validate_same_iteration`) and requires re-execution is probably possible but not very straightforward
/// and it's easy to get it wrong, which results in infinite loops where `Memo::provisional_retry` keeps retrying to get the latest `Memo`
/// but `fetch` doesn't re-execute the query for reasons.
///
/// Specifically, a Memo can linger after a panic, which is then incorrectly returned
/// by `fetch_cold_cycle` because it passes the `shallow_verified_memo` check instead of inserting
/// a new fix point initial value if that happens.
///
/// We could insert a fixpoint initial value here, but it seems unnecessary.

I also used this PR as an opportunity to add some more logging which should help debug similar issues more easily in the future.

[netlify]

✅ Deploy Preview for salsa-rs canceled.

Name	Link
🔨 Latest commit	c0f2c21
🔍 Latest deploy log	https://app.netlify.com/projects/salsa-rs/deploys/68d4152c324e7e00087ac9f4

[codspeed-hq]

CodSpeed Performance Report

Merging #993 will improve performances by 11.24%

_{Comparing MichaReiser:cleanup-provisional-memos-on-panic (c0f2c21) with master (e257df1)}

Summary

⚡ 4 improvements
✅ 8 untouched

Benchmarks breakdown

	Benchmark	BASE	HEAD	Change
⚡	amortized[Input]	2.4 µs	2.2 µs	+11.24%
⚡	amortized[InternedInput]	2.3 µs	2.1 µs	+10.33%
⚡	amortized[SupertypeInput]	3 µs	2.8 µs	+5.79%
⚡	new[InternedInput]	4.6 µs	4.3 µs	+7.01%

[MichaReiser]

This is something that's sort of impossible to test reliably without shuttle but shuttle still deadlocks (when I'm very confident that it shouldn't because there's a log resuming the deadlocked thread directly one line above)

[carljm]

Any idea why this is improving several benchmarks? Seems surprising. Is that just noisy benchmarks? That also seems surprising that it would be consistent improvement across four different ones.

[MichaReiser]

Any idea why this is improving several benchmarks? Seems surprising. Is that just noisy benchmarks? That also seems surprising that it would be consistent improvement across four different ones.

Nope. Maybe the first change that builds with Rust 1.90?

[carljm]

Nice!