Optimize MV Memory's concurrent hash map

[hai-rise]

• Better structure than the current BTreeMap.
• Fine-tune the number of shards.
• Batch writes by shards instead of repeatedly locking and unlocking the same shard.
• MV Memory has a u64 key that we can use directly for determining the shard.
• Estimate more locations during preprocessing.
• We want a lock-free API to construct estimated locations.
• dashmap is not perfect, for instance: performance reduced in 6.x xacrimon/dashmap#306.
• We may benefit from designing a specialized concurrent hash map for our use case.
• We may benefit from designing a specialized memory allocator for MV Memory.

[malik672]

@hai-rise assign me

[hai-rise]

@malik672 Thank you for your interest!
This is a pretty broad task. Perhaps we can break it down in Telegram DM (find me @hai_nq) before tackling it 🙏?