This causes problems on multi-homed GFE and Sunshine (prior to v0.21) hosts
because audio and video data can be sent back from an address different than
the one we used as our original destination address.
This reverts commit c13f4a323f.
This means we can ensure a consistent local address for our outgoing PING
traffic to keep the UDP flows alive without having to call connect() which breaks
with multi-homed hosts on GFE and Sunshine v0.20 and earlier.
The batch delay will basically always trigger for motion reports that contain both accel and gyro
data (like PS4/PS5 controllers) because we will report accel and gyro data within 1 ms every time.
This gets even worse when multiple controllers are connected and reporting motion data.
There shouldn't be any real need to batch these because they're unreliable sequenced packets,
so we can just remove the delay.
The old method was too inflexible (depending on consecutive events to batch) that it couldn't
really handle stressful cases like high polling rate mice combined with multiple gamepads
reporting motion sensor events.
It's possible for a sequence of packets seqnums like 2, 0, 1, 2 to end up hitting the fast path
again after filling in gap of OOS packets. The fast path assumes duplicate packets are caught
by the next contiguous sequence number check, but this is only true if that value is kept updated.
Since the slow path doesn't update the next contiguous sequence number, it's no longer safe to
use the fast path for the remaining packets in the frame because duplicate packets would be
mishandled.
Queuing duplicate packets violates all sorts of queue assumptions and can cause us to return
corrupt data to the decoder or attempt an FEC recovery without enough shards.
Time spent processing client callbacks would contribute to increased control stream latency,
which means higher RTTs, more lengthy waits before retransmissions, and higher client-reported
network latency stats.
Since we always allocate fixed size these aren't likely to be exploitable,
but we ought to fix them anyway. Worst case, we will just read some garbage
and generate corrupt video output.
