Allow fallback to take more than one iteration to converge

[carljm]

The Fallback option for fixpoint iteration has proved not very useful in practice, due to the requirement that the fallback value must converge in the very next iteration. In order to make it more useful, allow it to converge in any number of iterations. In other words, with this PR it is no longer an immediate fallback (that option is covered by FallbackImmediate), instead it allows "jumping" fixpoint iteration to a new point, and iterating from there. It is up to the user to provide a fallback value that will converge, otherwise it is still possible to reach a "too many iterations" panic after returning Fallback.

I have a working proof-of-concept in ty of using this new capability to avoid "too many iterations" in divergent cases by falling back to a Divergent type.

[netlify]

✅ Deploy Preview for salsa-rs ready!

Name	Link
🔨 Latest commit	7f0d2a0
🔍 Latest deploy log	https://app.netlify.com/projects/salsa-rs/deploys/68c192bb4c2ebc00082c3afc
😎 Deploy Preview	https://deploy-preview-991--salsa-rs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[codspeed-hq]

CodSpeed Performance Report

Merging #991 will not alter performance

_{Comparing carljm:fall-back-converge (7f0d2a0) with master (a0e7a06)}

Summary

✅ 12 untouched benchmarks

[ibraheemdev]

This makes sense to me. Do you think Fallback is still a good name for the operation, as opposed to something like Restart?

Also, should the test here be using FallbackImmediate?

[carljm]

Fallback might not be the best name. Not sure about Restart either. Maybe ContinueWith or IterateWith?

I don't think that test needs to use FallbackImmediate; it works fine with Fallback because it converges.

[carljm]

FallbackImmediate isn't even a CycleRecoveryAction, it's a separate way of configuring a query in the first place.

Looking at a rename, it seems like maybe CycleRecoveryAction should just go away and the cycle recovery function can just return an Option of the query return type instead? It's a bit weird to have an enum where the only two options are CycleRecoveryAction::Iterate and CycleRecoveryAction::IterateWith, where both options continue iterating and the only difference is whether a new value is provided.

I think I'd prefer to land this with minimal API changes for now, and revisit API changes / renames later. I have some other possible features in mind that would also change the API (e.g. having the cycle recovery function accept the latest and previous iterations' values, to help users maintain monotonicity), and it would probably be best to do the API changes together if possible.