blk/KernelDevice: Introduce a cap on the number of pending discards

blk/KernelDevice: Introduce a cap on the number of pending discards

Some disks have a discard performance that is too low to keep up with
write workloads. Using async discard in this case will cause the OSD to
run out of capacity due to the number of outstanding discards preventing
allocations from being freed. While sync discard could be used in this
case to cause backpressure, this might have unacceptable performance
implications.

For the most part, as long as enough discards are getting through to a
device, then it will stay trimmed enough to maintain acceptable
performance. Thus, we can introduce a cap on the pending discard count,
ensuring that the queue of allocations to be freed doesn't get too long
while also issuing sufficient discards to disk. The default value of
1000000 has ample room for discard spikes (e.g. from snaptrim); it could
result in multiple minutes of discards being queued up, but at least
it's not unbounded (though if a user really wants unbounded behaviour,
they can choose it by setting the new configuration option to 0).

Fixes: https://tracker.ceph.com/issues/69604
Signed-off-by: Joshua Baergen <jbaergen@digitalocean.com>
(cherry picked from commit 1dee8837959075687ea8a81c4eec2e1c6625e486)