[tintinhamans]

Merge after #660.

Every player sent its commands to the packet router only and the router forwarded them, so a command of a non-router player took two hops and the router's upload carried the whole match. The mesh is already fully connected, so the second hop is extra latency and extra load on one machine.

With send.direct (true) every player sends its commands straight to each peer while every active peer has a direct mesh connection, and the acks come back from each peer. ConnectionManager::isDirectSendActive rechecks the links every 250 ms and logs [DIRECT] when the mode changes. When a connection drops or is not direct, commands fall back to the packet router. A peer that is quitting does not count, and a frame's latency is the slowest peer's round trip.

The arrival decides how a command is acked: one that came straight from its author is acked to it, one the router passed on is acked to the router, so peers in different modes still drain each other's acks. If the transport does not say who sent a packet (anticheat transport), the receiver's own mode is used. A peer that stops acking but is not yet removed holds back that frame's latency measurement until it is pruned, so the measured delay can be stale for those seconds.

send.direct is the only new key, on by default as in the tester build, and the service can turn it off. No wire change.

Tested: builds x86 Release z_generals. In the 3 player rig (full stack) a forced mixed direct and relay link drained its acks, 0 CRC mismatches, n=1.