`--def-ttl` doesn't work on Windows (7): `setsockopt IP_TTL: 10022`

[EvgenKo423]

Environment: Windows 7 SP1. ByeDPI v0.13.1+ at least. Reproduce Steps:

1. Run proxy with ciadpi.exe -i 127.0.0.1 --def-ttl 4;
2. Try to open any website.

Expected Result: TTL is set. Actual Result: Error setsockopt IP_TTL: 10022.

new event: fd: 220, evt: EV_ACCEPT, mod_iter: 0
accept: fd=116
new event: fd: 116, evt: EV_REQUEST, mod_iter: 1
setsockopt IP_TTL: 10022
ss error: 0
close: fds=116,-1, recv: 0,0, rounds: 0,0

This happens only for new connections, --ttl for fake works.

[dartvader316]

Possibly problem like here:

https://docs.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-connect

If the connection is not completed immediately, the client should wait for connection completion before attempting to set socket options using setsockopt. Calling setsockopt while a connection is in progress is not supported.

[hufrea]

I suggest just removing this option for Windows. Setting TTL after connection may not give the expected effect and will only confuse.

[EvgenKo423]

Related to #90, --def-ttl works when socket is forced to IPv4 with --conn-ip.

TBH, I don't understand how this option may help with TTL detection: the DPI can just compare the fake TTL with TTL from previous packet and if they mismatch then it was changed. ~On the other hand, from my observations of how Russian DPI works, in some cases (e.g. googlevideo.com) setting --def-ttl per group in itself can be used as a bypass method (which is currently not supported). ;-)~

[hufrea]

This option can help to bypass mobile traffic tethering detection. TTL already needed to be changed (due to disorder, fake), so this side function was added.

Related to https://github.com/hufrea/byedpi/issues/90, --def-ttl works when socket is forced to IPv4 with --conn-ip.

It seems that mapped-addresses support should be disabled for Windows, but then there will be difficulties with --conn-ip.