Fixes clients occasionally getting kicked out the moment they're in sync, because their latest received ID is still set to the ID of the last unique event and the server thinks they're requesting some old event that doesn't necessarily exist anymore.
+ added a debug command that creates a ton of entity events
I noticed that if the main event IDs went over 10000 and there were more than 450 unique events, the server would sometimes skip the next event the client needed. Sometimes the client would also not realize that the last event it received was the final init event, so it would reject all further events because of a huge ID discrepancy. The init events will likely need to be reworked, but updating UnreceivedEntityEventCount seems to help somewhat.
Not sending the events at all would be a better solution, but then we'd need to shift the IDs of all the consecutive events and make sure it doesn't mess anything up with any of the clients. Not necessarily worth the effort, considering how rare these "empty events" are.
The clients didn't reset their ChatMessage.LastID, which caused an exception to be thrown when clamping the chatmsg ID server-side, preventing the server from updating the lastRecvEntityEventID of the client later in the method. The server wouldn't kick the client, because ServerEntityEventManager wouldn't handle cases where a client is waiting for an event that doesn't exist anymore.
Now they're kicked out if they're not in sync within 10 seconds of joining, TODO: calculate a reasonable timeout based on the amount of events and/or give the client more time if they keep receiving events
- comparing event data equality with Object.Equals instead of == because == returns false for boxed value types
- fixed old unacked messages not being resent if there are newer unacked messages that have been resent less than 1.5 * RTT ago
todo: add NetEntityEventManagers to server & client, some logic to prevent sending events that don't need to be sent (e.g. duplicate event state updates)
