#52 Multiple problems because MAX_DATAGRAM is set too large

[Simon Howard]

-protocol 15 is supposed to make QuakeSpasm use the original NetQuake protocol. However, the original Quake (DOS or WinQuake) can't actually connect to QuakeSpasm servers because the MAX_DATAGRAM constant got changed to a very large value at some point.

Compare:
https://github.com/sezero/quakespasm/blob/e1f17a90efa8dc051551568719fef6995c762445/Quake/quakedef.h#L84
https://github.com/id-Software/Quake/blob/bf4ac424ce754894ac8f1dae6a3981954bc9852d/WinQuake/quakedef.h#L102

Since MAX_DATAGRAM is 1024 in vanilla Quake, it can't receive any packets larger than this. A QuakeSpasm server will send packets too large for a vanilla client to receive and it will be unable to connect.

Furthermore, Datagram_SendMessage uses this constant to split large reliable messages across multiple packets:

https://github.com/sezero/quakespasm/blob/master/Quake/net_dgrm.c#L152

Since the constant has been set so large, the packets that get transmitted are jumbo frames that end up getting fragmented when sent over the Internet, which defeats the purpose of splitting across multiple packets in the first place. Worse, some cloud providers like Google Cloud don't support fragmentation, so if you try to run a QuakeSpasm server on a GCP VM it fails to connect.

[Ozkan Sezer]

This issue is inherited from Fitzquake.

Eric: QSS possibly has a fix for this. If it does, would you be willing
to extract a fix for us? (you are more familiar with qss than I am, and
qss diverged massively from qs.)