Flexible memo dropping behavior

[Veykril]

This allows users to opt-into receiving a channel receiver on storage creation that can be used to decide when and where to drop destructors of stale memo results.

Notably this does not yet handle LRU evictions, so those are still synchronous. Handling that is more complicated or will have to incur allocations so I am not yet sure how to best approach this. We could maybe consider a double buffer (triple buffer) approach for the deletion queues per ingredient instead and if those are exhausted fall back to blocking in case of too frequent revision bumps. That is something I will consider in a separate follow up PR though, for now this is ready for a review.

Note that the perf changes are noise due to allocation order differences.

[netlify]

✅ Deploy Preview for salsa-rs canceled.

Name	Link
🔨 Latest commit	afa442f
🔍 Latest deploy log	https://app.netlify.com/projects/salsa-rs/deploys/688f1e476edca3000816c27c

[codspeed-hq]

CodSpeed Performance Report

Merging #874 will not alter performance

_{Comparing Veykril:veykril/push-proytsnlytqr (afa442f) with master (c3f86b8)}

Summary

✅ 12 untouched benchmarks

[davidbarsky]

Three things:

1. I didn't know it was legal to write unsafe fn(NonNull<DummyMemo>). I'm guessing that if you pass it a safe closure, this will fail to compile?
2. Can you make these named fields instead of tuple structs?
3. I really think this should be tested with Shuttle. if you're okay with me pushing to your branch, i can do that?

[Veykril]

I didn't know it was legal to write unsafe fn(NonNull). I'm guessing that if you pass it a safe closure, this will fail to compile?

No, safe functions/closures can be coerced to unsafe ones just fine. After all calling a safe function in an unsafe context isn't problematic. Only the other direction won't work for obvious reasons.

The other two questions won't be relevant anymore once im finished writing out the new approach

[Veykril]

Okay, new approach. The user is now in charge of things. We now have two dropping modes, synchronous (what we currently have) and channel based, where the user will receive a receiver on storage construction that they can poll to drop things as they like.

[Veykril]

So, delaying the LRU clears is actually a bit more difficult and as it turns out, my previous approach was even unsound. We need to remove the values immediately, as otherwise we might be racing with computations of the next revision. That is a bit unfortunate though, as the values are not necessarily allocated and so we can't just take the pointer as an opaque droppable thing. That leaves two options, allocate LRU'd values that are to be dropped elsewhere individually, or use a (paged) arena allocator and move the value into that. Neither approach seems nice to me ...

[davidbarsky]

LGTM, but I think I'd prefer someone from Astral to also approve this—conflict of interest and all.