When programming the timer, eagerly raising a timer IRQ by software
via the pipeline for close shots (i.e. below the clock chip's minimum
delay) may cause such event to happen too early for the co-kernel to
actually deliver it to any handler, which in turn may trigger yet
another request for programming the timer with too close a delay, and
so on, until the current time eventually matches some pending event
date.

In such a case, the system may spend a lot of time trying to converge
on a proper trigger date by looping into the clock event handling
logic, delaying the co-kernel by the same amount.

To fix this, always go through the clock hardware for programming a
close shot with the minimum acceptable delay, which ensures that we
won't receive the next timer event too early.