When the display queue had is full and a new notification would come
in, new notification wouldn't get shown until a currently displayed
notification would timeout.
Even if the notification would have been shown on top of the displayed
queue. So e.g. if the displayed queue would have been filled with
"normal" urgency notifications, an incoming "urgent" notification would
have been delayed.
To let those more important notifications through, the tail of displayed
and head of waiting are swapped on every update if necessary.
For notifications without any timeout, ttl can't be positive.
So when, show_age_threshold is active, dunst won't wake up, if there
are only notifications displayed without any timeout.
On Linux, CLOCK_MONOTONIC has got a bug. It does not count
onwards during sleep, albeit required by POSIX. This behavior
is reasoned with the requirement for poll().
Also the GLib people are sticking to this behavior in their
g_get_monotonic_time() function.
So we have to use a drop in replacement, which respects CLOCK_BOOTTIME
on Linux, as this is the clock, what would be CLOCK_MONOTONIC on POSIX
systems.
The signal_notification_closed function is called even when a
notification has been pulled from history and re-emits the
NotificationClosed signal, this can confuse clients since multiple such
signals are not accounted for in the spec.
Notification spec prohibits to reuse notification IDs (unless uint32 is
exhausted). Therefore returning the same ID twice must not happen.
Sending a signal, that the old notification timed out makes most sense.
It wasn't closed by the user, nor by a CloseNotification call either.
When we stack notifications, no interaction happened (the equivalent
of timing out).
Move all id-changing functions out of notification_init and handle this
in queues.c
Also use stack_duplicates in combination with replacement of
notifications correctly. Fixes#404 (issue not found)
