5ms MAX_IDLE_WAIT in xi_rpc::next_read leads to unwanted CPU utilization

xi_rpc::next_read currently implements naïve busy-polling to service multiple task sources in a non-blocking manner. This is done by attempting to read from the peer with a very short timeout, and if the timeout is met, try to service other "background tasks".

A more appropriate implementation would either be a proper poll that blocks indefinitely on all sources, or something along the lines of an mpsc select! across multiple channels.

On an ultrabook idling at 800MHz, a busypoll with 5ms timeout leads to ~1% reported CPU utilization, which is a lot for doing nothing.