metrics: record time to update gc info as a per timeline metric

[koivunej]

We know that updating gc info can take a very long time from recent incident, and holding Tenant::gc_cs affects many per-tenant operations in the system. We need a direct way to observe the time it takes. The solution is to add metrics so that we know when this happens:

• 2 new per-timeline metric
• 1 new global histogram

Verified that the buckets are okay-ish in dashboard. In our current state, we will see a lot more of Inf, but that is probably okay; at least we can learn which timelines are having issues.

Can we afford to add these metrics? A bit unclear, see another dashboard with top pageserver /metrics response sizes.

[github-actions]

2772 tests run: 2654 passed, 0 failed, 118 skipped (full report)

---

Code coverage* (full report)

• functions: 28.1% (6466 of 23044 functions)
• lines: 46.8% (45690 of 97613 lines)

* collected from Rust tests only

---

_{The comment gets automatically updated with the latest test results
22592a2 at 2024-04-23T07:22:29.195Z :recycle:}

[problame]

No strong objections, some comments.
And I don't have opinions on whether we can afford the additional metrics.

[koivunej]

We discussed this more last week. The guess is that we should have room for this metric, so merging.