[Adhoc] Attempt to prevent sockets lingering in TIME_WAIT state after closure

[anr2me]

Based on https://stackoverflow.com/questions/58506815/how-to-apply-linger-option-with-winsock2
Which might be related to port-remapping (ie. "Data from Unknown Port") issue on external/public IP, quoted from NAT traversal:

if two internal hosts attempt to communicate with the same external host using the same port number, the NAT may attempt to use a different external IP address for the second connection or may need to forgo port preservation and remap the port.

Basically, if the socket is internally still in TIME_WAIT state (up to 4 minutes) waiting for FIN-ACK/RST from remote side. the connection to the remote side might still exist on the NAT, thus when creating another socket using the same combination of internal IP:port to communicate to the same external IP:port could result to either using a different public IP (less likely) or remapped to a different public port (most likely).

With the way how adhoc games often recreate the socket when reaching a timeout to retry (which usually using a short timeout), or when switching from host/join mode, or the player going in/out the lobby multiple times in quick succession triggering AdhocMatchingStart/AdhocMatchingTerm, might be triggering this port-remapping issue.

PS: I haven't tested this PR since my internet couldn't do port forwarding in the first place, so this PR need to be tested by people who often get port remapping issue.

And currently we didn't detects any possibility of IP changes, since we ignored any data that came from IP that doesn't exist in the player/friend list provided by the AdHoc Server anyway, thus won't be useful even when we can detects Data from Unknown IP, as we don't know which player it belonged to. (well, may be can be done with the help of SIOCGARP/ARP request to keep track of the real MAC address as reference to IP, which probably only works on LAN)
But, we should probably shows a message when we detects Data from Unknown IP to tells the player that there could be abnormality in communication (in the case it was due to NAT), or a stranger attempting to do something through that port (which is related to network security)

PPS: Alternative to using shutdown(fd, SD_RECEIVE); is by not calling shutdown at all, but if the are left over packets that are still on the way (ie. due to high latency) those packets might still be received by the kernel and passed it to the next socket that quickly use the same internal port, thus could cause a confusion.
I've seen this kinda issue long ago while testing a game (was it Warriors Orochi 2?), where after both players going in/out lobby many times, a strange 1 byte packet got received even when the other player haven't joined the lobby yet, where i thought another device/program on the same network might be broadcasting something and happened to use the same port, but i couldn't find any other program that use that port, so it was a mystery to me back then.

[hrydgard]

Seems worth a try - let's get it in and see what happens!

[hrydgard]

@anr2me Just noting that this somehow ended up causing AdHoc localhost multiplayer problems: #20224. Although since the issue is talking about a custom game mode, I don't know how much that applies to the vanilla games.

[anr2me]

May be we should try the alternative way, by not calling shutdown before closing the socket 🤔