db: shared compaction concurrency limit across multiple Pebble instances

[sumeerbhola]

In CockroachDB multi-store deployments, especially with large numbers of stores (8 or more), the CPU consumed by compactions can be significant. We do need a per store compaction concurrency limit, since disk bandwidth is a per-store resource, but we should additionally have a shared compaction concurrency limiter.

This shared limiter should fairly adjudicate on which compaction gets to run next based on a score of how important it is. For example,

• level score driven compactions could be compared based on the score, or additionally take into account the number of sub-levels if this is a compaction out of L0.
• a read-driven compaction in one store is strictly less important than a score driven compaction in another store.
• delete-only and move compactions are cheap, so don't need to respect this concurrency limit.

Jira issue: PEBBLE-230

[sumeerbhola]

NB: this is orthogonal to https://github.com/cockroachdb/pebble/issues/1329 which would adjust the node-level concurrency limit based on the available CPU. We would still need a limiter component that would decide which among the queue of potential compactions gets to run next.

[itsbilal]

Cockroach side issue, if we explore a solution higher up: https://github.com/cockroachdb/cockroach/issues/74697