sched: correctly fix for timer re-set bug

In commit 870d8410, Avi fixed a bug where if a timer_base::timer_fired()
function re-sets the same timer that fired, timer_list::fired() erroneously
removed the timer from the list after the timer being re-set. The fix in
that commit was to avoid removing the timer from the timer_list if the timer
is still armed after the call to timer_fired().

Unfortunatley, that commit didn't quite make timer re-set work. When I tried
now to use timer.set() in timer_base::timer_fired(), for implementing timerfd,
I discovered it still doesn't work: the set() tries to add the timer to the
timer_list while it is still on it, resulting in assertion failure.

The right thing to do is to first remove the fired timer from the list,
and only then call timer_fired(). If timer_fired() wants to set the timer
again, it can - but anyway, it will always set the timer with a different
time, so the timer will anyway occupy a different position in the sorted list,
so the right thing is always to remove the timer from the list and then
add it to the right place if we want.

I'm curious, by the way, what commit 870d8410 actually solved, and if
we could check this fix doesn't ruin it. All tests appear to still pass
with this patch (and also the new timerfd test).

Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>
Reviewed-by: Tomasz Grabiec <tgrabiec@gmail.com>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>