Running event loop based transport

[cheme]

mio (metal io) usage, special kind of transport being eventloop kind (trait Evented of tcpstream), on receive : server , easy you register an eventloop (more a single thread) for accepting socket and managing multiple (determinist number) ev loop : in transport impl, then instead of starting many thread you just register token in a loop (maybe conf nb of token per loop in transport) or more so 2 thread or more. Client is not as easy since it means replacing channel of route per eventloop ref and token (ref if possible multiple event loop), then send will write in event loop.
Eventloop handler for client is same code as when receiving in channel, in server it is same code as match on recv.
Reconnect once of client : ???
Maybe need generic interface for this kind of loop, need specific transport : tcp mio will be same as tcp, but a kind for this transport leading different code in server and peermanager/client which will not spawn.
This is quite doable fast but not to clean since transport interface does not really fit (with current mio design its ok), and procs code involve mio dependencies plus some nasty conditional everywhere (already the case with disconnected transport). Further refactor should involve non blocking transport and removal of proxy mode (but out of scope for now).

Two major point :

• Usage of event loop require first full asynch ping : [https://github.com/Some ping should run asynch #41].
• Proxy mode redesign is out of scope, it will simply block (with current mio design it seems possible) a lot but anyway proxy mode is just meh (usefull for some debug or very special cases). Just maybe disable it with custom rules (see [https://github.com/Query Mode filtering #44]).