Tracking: control async table hook background resources

[KKould]

Summary

Async table hooks can run compact/recluster/refresh/analyze work in the background. Compact and recluster are IO- and memory-heavy, so we should track whether async hook workers can affect foreground SQL latency when the system is busy.

Follow-up ideas

• Review whether table_hook_async_max_concurrency is enough as the first-level control.
• Consider lowering background hook concurrency when foreground SQL load is high.
• Consider IO/memory throttling for background compact/recluster work if settings-level controls are not enough.
• Add lightweight checkpoints inside long-running background work or loops, for example:

loop {
    while check_busy() {
        sleep(...)
    }
    do_next_background_step()
}

This would let async hook work yield when foreground load is high, then resume when the system is idle.

• Keep the current PR simple; compact/recluster already have related settings, so this can be handled as follow-up work.

Related

• Async table hook PR: feat(query): support async table hooks #19962