Fix hanging core-relations tests.

[ezrosent]

Described this more in slack. There were two issues I found when looking through backtraces of hanging tests:

1. Concurrent calls into the allocator during SortedWritesTable::merge were causing things to slow way down. To fix this, we add MiMalloc. We may want to gate this behind specific platforms in a future change.
2. We were accidentally holding onto a dashmap lock during the index cache lookup code. This may have caused a deadlock (rayon calls itself recursively, but the index refresh code that takes up most of the accidental critical section actually has its own thread pool), but at the very least it probably forced a lot of parallel code to convoy in a very slow way.

Thanks to @yihozhang for finding the connection with the index cache.

[ezrosent]

Seems like you can get another issue:

• Index not cached before
• Start FJ, look up new index, start to build it in parallel, this causes us to spawn a ton of tasks in the thread pool then do other tasks while waiting for those to finish.
• One of those tasks may be continuing the FJ. potentially by looking up the same index. Index lock is held? Deadlock

Or something along those lines, at least. That one happens more rarely but will be trickier to fix.

[ezrosent]

b427c2a doesn't do the right thing. It actually runs most of the stuff on the parent thread pool, so the problem is still there.

[yihozhang]

Thanks for the fix! This looks good

Do we still need the mimalloc allocator for tests?

[ezrosent]

I think I'll keep it in for now. Unfortunately we still get some weird excursions without it. I was able to get this after ~8 runs on a non-release build:

PASS [ 14.141s] core-relations tests::ac_fj_puresize

Normally takes 166ms.