perf: fix bucket queue timer loop

[Usiel]

Noticed this while profiling for other work.

Fix

When there is no work on the BucketQueue it ends up rescheduling itself constantly, which causes 2.9% of the main thread to spend time on just setting and clearing timeouts. On my machine I get roughly 650 tasks per second due to the BucketQueue's constant rescheduling.

We can optimize this by only running the scheduler when there is work in the bucket and avoid causing any work on the main thread when there is no work to do.

Test

I added tests that are green for both the new and old implementations, demonstrating that the change doesn't actually change any relevant behavior.

Release

Other changes:

• Improve performance and energy usage by reducing work executed when idle

[dmsnell]

Can you explain how this works? What the idea is behind the deadlines, and explain why it was already scheduling as it was?

What could go wrong or be missed by the updated scheduling process?

[Usiel]

Previously, there was a bug that could lead to constant rescheduling. this.nextDeadline represented the earliest queued sync deadline, but it never increased. It was not recomputed when the queue changed, so after the earliest item was processed, this.nextDeadline still pointed to a time in the past.

With this change, the intended behavior is more explicit imo. The next deadline is always (re)computed from the current queue contents. This trades a tiny bit of performance for correctness and readability.

What could go wrong or be missed by the updated scheduling process?

The main risk would be if queue contents changed without going through add(), since add() is what schedules the next timer. With the class as it is today, queue is internal and add() is the public entry point. Other public methods are read-only.