Fix maybe_changed_after runnaway for fixpoint queries

[MichaReiser]

This PR fixes a few bugs related to maybe_changed_after and fixpoint iteration.

Runnaway

The most important fix is for a runaway issue where maybe_changed_after revalidates the same queries repeatedly, see #960.

Given a query:

a -> b -> a
       -> c

C doesn't participate in the cycle, but we didn't mark it as verified before this PR because the outer query `a is participating in a not-yet-resolved cycle.

This PR fixes this by tracking the cycles per query (each subtree tracks the cycles independently). I added cycle_sibling_interference as a regression test.

validate_same_iteration

maybe_changed_after internally calls deep_verify_memo, which, on master, calls maybe_validate_provisional, which calls validate_same_iteration. validate_same_iteration returns true for a provisional query if the cycle heads between its cycle head entries and the latest available memos for those cycle heads have the same iteration count. This is important in fetch, where we want to reuse cached query results during a fixpoint iteration.

However, we shouldn't return Unchanged in maybe_changed_after for a memo that's not finalized but validate_same_iteration returns true because we simply don't know yet if that value has changed or not (we need to wait for its cycle heads to resolve).

This PR moves the validate_same_iteration check out of deep_verify_memo and instead duplicates it inside fetch_cold and maybe_changed_after_cold, where only fetch_cold returns early when validate_same_iteration returns true.

I tried to write a regression test for this but I failed. However, we have an incremental integration test in ty that starts failing without this change (because a query now returns an outdated result).

Re-execution and provisional memos

If there are no pending cycles in maybe_changed_after and there's an old memo, Salsa executes the query again and then compares the last_changed_at with the revision passed to maybe_changed_after to decide if the value has changed.

This PR adds an additional check to only return unchanged if the value isn't provisional.

I don't know if this is a 100% necessary and I failed to write an integration test for it (and no test in ty fails). So it might be that some other combination of checks prevent this but I can't say for sure. That's why I added the check.

[netlify]

✅ Deploy Preview for salsa-rs canceled.

Name	Link
🔨 Latest commit	3a7e731
🔍 Latest deploy log	https://app.netlify.com/projects/salsa-rs/deploys/6895ea0591413a00099da61c

[codspeed-hq]

CodSpeed Performance Report

Merging #961 will not alter performance

_{Comparing MichaReiser:maybe-changed-after-fixpoint (3a7e731) with master (22a4d99)}

Summary

✅ 12 untouched benchmarks

[MichaReiser]

The output before this change was:

[
    "salsa_event(WillExecute { database_key: min_iterate(Id(0)) })",
    "salsa_event(WillExecute { database_key: min_iterate(Id(1)) })",
    "salsa_event(DidValidateMemoizedValue { database_key: min_panic(Id(2)) })",
    "salsa_event(WillExecute { database_key: min_panic(Id(3)) })",
    "salsa_event(WillIterateCycle { database_key: min_iterate(Id(0)), iteration_count: IterationCount(1), fell_back: false })",
    "salsa_event(WillExecute { database_key: min_iterate(Id(1)) })",
]

Note how c (min_panic(Id(2))) doesn't get verified as part of a's deep_verify_memo. Instead, it only gets verified once a re-runs.

[davidbarsky]

a few nits/asks for clarification

[MichaReiser]

The failing test is related to Rust 1.89

[carljm]

Looks good, thank you!