threadshare: busy wait in elements that schedule timers closer in the future than `context_wait` / 2
@fengalin I wonder what your take on this is:
In the threadshare jitterbuffer for instance, the element determines when it needs to wake up to push the next item, goes to sleep then checks if the next element is indeed ready.
The problem is that when it wakes up too early, it determines that "now" is still too early for the next item, and goes back to sleep for a duration < context_wait / 2 (using delay_for), wakes up immediately, rinse repeat until time for the next item has actually been reached.
I'm not sure what the best fix for this is: should our tokio fork always delegate timers to the "next" time frame, accepting that timers could be up to context_wait "late", or should jitterbuffer always pop the next item when it woke up without getting unscheduled (which can happen when a new item was queued while sleeping)?