Our existing metrics are gauges (total and used slots) which don't give us
insight into what is happening at smaller time scales. This creates
uncertainty when we observe admission queueing but the gauge samples show
total slots consistenly greater than used slots. Additionally, if total
slots is steady during queuing, it doesn't tell us whether that was because
of roughly matching increments or decrements, or no increments/decrements.

The following metrics are added:
- admission.granter.slots_exhausted_duration.kv: cumulative duration when
  the slots were exhausted. This can give insight into how much exhaustion
  was occurring. It is insufficient to tell us whether 0.5sec/sec of
  exhaustion is due to a long 500ms of exhaustion and then non-exhaustion
  or alternating 1ms of exhaustion and non-exhaustion. But this is an
  improvement over what we have.
- admission.granter.slot_adjuster_{increments,decrements}.kv: Counts the
  increments and decrements of the total slots.
- admission.granter.cpu_load_{short,long}_period_duration.kv: cumulative
  duration of short and long ticks, as indicated by the period in the
  CPULoad callback. We don't expect long period ticks when admission
  control is active (and we explicitly disable enforcement during long
  period ticks), but it helps us eliminate some hypothesis during
  incidents (e.g. long period ticks alternating with short period ticks
  causing a slow down in how fast we increment slots). Additionally, the
  sum of the rate of these two, if significantly < 1, would indicate that
  CPULoad frequency is lower than expected, say due to CPU overload.

Fixes cockroachdb#92673

Epic: none

Release note: None