fix(bloomplanner): Skip queue_length metrics cleanup while tenant queue is non-empty

[o6ivp]

What this PR does / why we need it:

The active-users cleanup ticker only saw Enqueue traffic, so a tenant whose backlog was being drained for longer than the inactivity timeout (1h) without any new enqueues had its loki_bloomplanner_queue_length series deleted mid-drain. Subsequent Dequeue calls then lazily recreated the series and decremented it into negative values.

Gate the per-tenant metrics cleanup on the queue actually being empty — if RequestQueue.GetUserQueueLength(tenant) is non-zero we skip metrics.Cleanup and re-register the user so a future tick can purge the metrics once the backlog drains. The empty-queue check is the necessary-and-sufficient condition: it covers backlogs being slowly drained (the original report) as well as the case where Dequeue itself stops happening for longer than the inactivity timeout (e.g. all builders busy on other tenants), which a timestamp-refresh approach could not protect against.

Which issue(s) this PR fixes:
Fixes #19490

Special notes for your reviewer:

The bug only surfaces on the bloom planner because its tasks are long-lived relative to the 1h inactivity timeout; other consumers of pkg/queue (query frontend, scheduler, bloom gateway) drain in seconds and never reach this state.

NewQueue is split into a public default-timing wrapper and an internal newQueue that takes the cleanup interval and inactive timeout, so the regression test can exercise the cleanup path in milliseconds instead of hours.

RequestQueue.GetUserQueueLength is added on pkg/queue so the bloomplanner cleanup callback can read the live per-tenant count under the queue's mutex.

Checklist

• Reviewed the CONTRIBUTING.md guide (required)
• NA Documentation added
• Tests updated
• Title matches the required conventional commits format, see here
• NA Changes that require user attention or interaction to upgrade are documented in docs/sources/setup/upgrade/_index.md

---

Note

Medium Risk
Touches bloom planner queue cleanup behavior and adds a new RequestQueue method used under lock; incorrect interactions could cause stale metrics or cleanup not firing, but scope is limited to metrics/housekeeping logic.

Overview
Prevents loki_bloomplanner_queue_length (and related per-tenant metrics) from being cleaned up while a tenant still has pending work, avoiding series recreation and negative decrements during long drains.

NewQueue is split into a default wrapper plus an internal newQueue that accepts cleanup timings (used by tests). The active-user cleanup callback now checks RequestQueue.GetUserQueueLength() and re-registers the user instead of cleaning metrics when the queue is still non-empty.

Adds RequestQueue.GetUserQueueLength() and a regression test that simulates millisecond-scale inactivity timeouts to verify metrics persist during draining and are removed after the queue empties.

^{Reviewed by Cursor Bugbot for commit 22c0eb4. Bugbot is set up for automated code reviews on this repo. Configure here.}

[chaudum]

I wonder whether it would make more sense to check the queue length of an inactive user before cleaning up the their metrics.
It could still be the case that there haven't been any dequeue operations for more than the inactive period.

[o6ivp]

Thanks, took the suggestion in 22c0eb4.