Not Fired timers leak into the kernel

[franz1981]

This has been reported by @pveentjer in a private conversation about io_uring Netty mechanics.

1. schedule a timer in 2 minutes
2. await till the IoUring event loop park/wait
3. schedule a second timer 10 seconds which is going to replace the last deadline set
4. once it fires, the next in-line scheduled task was the previous one of 2 min(now <= 1m50s, likely): the event loop arm a timer for this deadline (<= 1m50s) BUT there was already such a timer, hence we arm it twice!

If we have a huge amount of already registered timers in the future, they will see their registrations to always happen twice, if their deadline is replaced with a new recent one.

Update the timer through a remove (via IORING_TIMEOUT_UPDATE) require >=5.11, while removing the existing one (when the new recent one need to be armed) is >=5.5.
There are several ways to address it, including NOT addressing it, but it can still cause silently to goes OOM or worse (no idea really).

I believe we had no covering for this because our await operations didn't allow any level of concurrency: if we block awaiting, is a blocking operations, period. But if we request to be awaken in the future, and we're awaken earlier, the same "in flight" request is not yet completed, hence allow to enqueue more and more of this.

[franz1981]

@chrisvest @normanmaurer Netty 5 is affected the same I think