Prevent timer wheel from growing unexpectedly

[cmeissl]

A client cancelling and inserting timers at high rates could result in the used heap to grow unexpectedly.
This can for example happen if a compositor tracks inactivity using a timer and receives a lot of pointer events in a single dispatch.

Currently TimerWheel::cancel can result in just marking a timer cancelled without the timer being actually removed
from the heap. So there might be a time-frame where the heap grows quite big holding mostly cancelled timers.
TimerWheel::next_expired is expected to clean-up the cancelled timers, but at this point the heap might have already
grown quite big and BinaryHeap::pop will not implicitly shrink its backing store.
Also I am not completely sure this will catch all usage patterns as TimerWheel::insert could result in re-ordering
of the heap.
(Note: Calling shrink might also bring the memory consumption down, but this might result in constant re-allocation)

Calling TimerWheel::cancel might already result in linear search in the heap to mark a timer cancelled,
so imo using retain does not make this worse but should keep the heap at a reasonable size.
This might also have the side-effect of making some operations like next_expired a bit faster for some use-cases.

fixes #233

[notgull]

@cmeissl Please rebase on master for CI fixes.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.17%. Comparing base (b1dbe00) to head (242cfad).
⚠️ Report is 3 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #238      +/-   ##
==========================================
+ Coverage   85.47%   86.17%   +0.69%     
==========================================
  Files          14       16       +2     
  Lines        1825     1997     +172     
==========================================
+ Hits         1560     1721     +161     
- Misses        265      276      +11     

Flag	Coverage Δ
macos-latest	85.48% <100.00%> (?)
ubuntu-latest	85.76% <100.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[cmeissl]

@cmeissl Please rebase on master for CI fixes.

done, thanks for taking care of the CI issues!

[cmeissl]

@notgull Do you think it is possible to get a release with the PR applied soon? Looks like quite a lot of people are affected in niri and cosmic-comp by this issue.