[HPA] Add pool of empty pages to hpa_central

[spredolac]

Motivation
If we already have huge and empty page it may be more efficient to donate it to another hpa shard, then purge and fault it again. This also helps somewhat with virtual address space as one would get the already allocated hpdata object if it is available in the pool before creating another one.
On some of the internal workloads we see improvement in memory, and on some we saw small CPU improvements when using pool.

What
Two commits are plain refactor - moving central related code out of the hpa.c and moving some utility functions into a separate module. Last commit is adding simple page pool which is effectively mutex guarded two lists (purged and non-purged empty folios) that each shard can borrow from.

Testing
Added some unit tests, and also tested in production using internal workloads.

[spredolac]

This explains why certain things are needed in the following commit when this comment is not necessary anymore.

[spredolac]

Will fix this formatting

[guangli-dai]

Discussed offline and concluding the discussion here:

1. The two refactoring commits look good. They isolate different modules of HPA codes more reasonably. We want to take the refactoring commits in first.
2. Adding a central pool is surely what we want in the long term. However, when to donate an empty 2MB units to the pool needs more discussion. If we donate soon, we can theoretically reduce the fragmentation. However, the contention in the central pool also grows rapidly. We want to use bpf to understand the frequency of such contentions and will likely go with a time-based demoting in this case. In short, the pool part needs more experiments and discussions to make the CPU-memory trade-off more efficient as well as configurable.

[guangli-dai]

Discussed offline and here is the latest update: By canarying on internal services with over 100M/s requests, we are seeing very trivial contention, i.e., 0 n_waiting/s, 40 n_lock_ops/s, and 0 total_wait_ns/s. Moreover, these experiments were conducted with a more aggressive policy which share the empty 2MB units once we have them empty, leading to heavier global hugepage pool usage.

This means:

1. the global hugepage pool already has enough caching level above it making contention not a concern here.
2. When the architecture inside HPA changes and when the range of allocations served increase (current experiments only involve <=32KB allocations because larger allocations have different patterns and need separate HPA shard to be packed efficiently), the global hugepage pool contention should be revisited.
3. We need to make a decision on whether we share the empty pages aggressively or conservatively. This can differ based on the sizes.

To conclude, with some nits, i.e., moving stats to "Merged arena stats", the PR is OK to merge. But we will probably hold this for a while until the planned cleanup and size rerouting is done.