chore(pageserver): shrink aux keyspace to 0x60-0x7F

[skyzh]

Problem

extracted from #7468, part of #7462.

In the page server, we use i128 (instead of u128) to do the integer representation of the key, which indicates that the highest bit of the key should not be 1. This constraints our keyspace to <= 0x7F.

Also fix the bug of to_i128 that dropped the highest 4b. Now we keep 3b of them, dropping the sign bit.

And on that, we shrink the metadata keyspace to 0x60-0x7F for now, and once we add support for u128, we can have a larger metadata keyspace.

Summary of changes

Checklist before requesting a review

• I have performed a self-review of my code.
• If it is a core feature, I have added thorough tests.
• Do we need to implement analytics? if so did you add the relevant metrics to the dashboard?
• If this PR requires public announcement, mark it with /release-notes label and add several sentences in this section.

Checklist before merging

• Do not forget to reformat commit message to not include the above checklist

[github-actions]

2820 tests run: 2700 passed, 0 failed, 120 skipped (full report)

---

Flaky tests (3)

Postgres 15

• test_gc_of_remote_layers: debug
• test_ts_of_lsn_api: debug
• test_pageserver_small_inmemory_layers[True]: debug

Code coverage* (full report)

• functions: 28.3% (6547 of 23140 functions)
• lines: 47.0% (46237 of 98454 lines)

* collected from Rust tests only

---

_{The comment gets automatically updated with the latest test results
bf7cb98 at 2024-04-26T16:19:50.579Z :recycle:}

[skyzh]

comments from @arpad-m -- if we can use the full u128 space in the future, metadata key now takes 75% of all prefixes, which does not seem reasonable.

Well, then let's split metadata keys at 0x60 in this pull request, so that it takes 25% now, and if we refactor everything to u128, metadata keys will only take ~60% prefixes? Or let's see if I can finish the u128 refactor before next month so that we can revert the keyspace back to 0x80 before rolling out to the users.