Netcode Overhaul

[Boondorl]

This PR includes a total overhaul to GZDoom's netcode with almost all of it being removed and replaced. For ages GZDoom's netcode has only been slightly better than its 1993 counterpart and this has led to a lot of headaches with simple tasks like:

• Setting up lobbies
• Getting everyone to actually connect
• Stability of the game once started

P2P in particular is problematic because while it works in LAN play, ISP configurations can cause users to be completely shut off from communicating with each other. Packet-server acted as a fix for this by having the host act as a middleman for routing packets instead of using direct communication, but this mode was incredibly laggy and prone to desyncs. Over longer distances (>80ms) it was unusable.

Most of these issues have been fixed. To start, the netcode has been further unhooked from the rest of the engine. While it was only a small amount, this PR manages to further isolate it reducing potential knock-on effects. Some strategies the main thread uses have also be re-evaluated for online play to ensure connection stability above all else. For instance, the wipe screens have now been disabled since they locked up the main thread and would cause bursty map change barriers that made the experience less comfortable. A particularly big change is that consistencies and inputs have been decoupled from each other, allowing input buffers to be sent over ahead of time helping reduce the stop and go nature of netplay.

Packet-server has been entirely restrategized to be usable over long distances. Now the host will act as the ultimate authority on the game's state and latency reducing measures have been put in place to improve the feel for all clients. The result is that the latency clients feel is now directly correlated to their round-trip time instead of the player with the highest latency dictating the base state of the game. Because of these changes, packet-server will now be the default mode for non-LAN play with 3+ players. The max player count has also been bumped to 16 because of this mode making this level of connectivity possible.

In preparation for future games being made publicly accessible, some features have been added to improve both the host's control and the client experience. Chat has been given new options including the ability to disable bold text via /me, mute the chat sound, and dictate what kind of chat messages (none/team/global) can be received. mute(all) and unmute(all) have been added for targeted muting. The non-all versions take a player number which can be gotten through listplayers (the * denotes which user the client is). kick has been added for hosts that wish to remove annoying users and they now have options to set both who can control pausing the game and if the chat should have slow mode (message throttling).

Other fixes include cleaning up TryRunTics to make it more inline with the new renderer. Some of the old code from 1993 remained that was used for tick control by locking up the main thread, but this strategy shouldn't be used when playing online and the renderer needs to be free to run immediately. In general the game will now handle lag outs far more gracefully. Instead of 3 seconds from the last update with a max of 17 commands in the buffer (including from the natural net delay), users can now generate up to 1 second worth of commands from the last time they updated, allowing for a smoother recovery since everyone will have the same level of commands in buffer. A few fixes for prediction have also been added to help improve the feel of the game during these lagging out periods.

On a final note, this will also impact demo support and this is currently untested. It's fully possible demos will be temporarily broken until they can be reworked later, however I have plans to fix this up and add more playback features for it to make GZDoom's demos more enticing. I'm not even sure they work as is so it's possible this won't actually affect their real viability to begin with.

[TheKins]

Pretty incredible stuff. We've been helping test it with an (unreleased, WIP) version of Reelism 2, and it's held up incredibly well to scenarios with 6-8 players on open maps with hundreds of active monsters and all sorts of Stupid Script Tricks being pulled on the regular.

A massive, essential improvement over the past situation.

[madame-rachelle]

I'm going to go ahead and merge this because this has already received a ton of testing and likely will receive a whole lot more, and this is by far one of the most anticipated features for 4.15. I'm fairly confident that if any regressions exist here they either will be found and fixed quickly or they already have been fixed.