Delay pools starvation

Ideas on how to avoid starvation when there is multiple connections
competing for a delay pool in the generic comm loop framework is
welcome.

Currently the comm loops take an overly simplistic view of delay pools,
and simply kicks all deferred connections alive once per second to have
them react on delay pools being filled up. But not too unexpectedly this
leads to a situation where some connections easily get starved.

In the old comm loops (still used for poll/select) delayed connections
is dealt with separately, randomizing their order.

Regards
Henrik