Harden the connection handshake against spoofed floods and amplification

[Segfaultd]

Summary

Make the connection handshake resistant to spoofed source floods and amplification abuse.

Problem

Two long standing weaknesses in the RakNet lineage wire protocol:

1. The peer allocates per connection state when the first ID_OPEN_CONNECTION_REQUEST_1 arrives, so an attacker sending spoofed packets can exhaust the remote system list without ever completing a handshake.
2. Some offline responses (unconnected pong with user data, open connection replies) can be larger than the request that triggered them, which makes the peer usable as a reflection/amplification vector.

Proposal

• Add a stateless challenge step (SYN cookie style): on the first request, reply with a cookie derived from an HMAC over source address, port, and a rotating server secret, and allocate no state. Only allocate the remote system entry when the client echoes a valid cookie.
• Guarantee that every offline response is no larger than the request that produced it, padding requests instead of shrinking replies where the protocol needs size probing (MTU discovery already pads from the client side).
• Rate limit unconnected pings per source address.

Compatibility

Gate the cookie exchange behind a protocol version bump in the offline message header so existing clients keep connecting; the relevant constants live in Source/include/mafianet/MessageIdentifiers.h and the offline message handling in RakPeer.cpp.

Acceptance criteria

• No heap or system list allocation happens before a valid cookie round trip
• Integration test proving a flood of spoofed ID_OPEN_CONNECTION_REQUEST_1 packets does not consume connection slots
• Unit test that every offline reply size is less than or equal to the triggering request size