MtProtoKit: fix pre-auth handshake reads could hang forever

[mvsrcdst]

Problem

---

If a proxy accepts the TCP connection but never responds during the handshake (proxy hangs, doesn't drop the connection, just never answers), the app hangs indefinitely with no error, no timeout, no way to recover except killing the app.

Root cause: -[MTTcpConnection socket:shouldTimeoutReadWithTag:elapsed:bytesDone:] unconditionally returned -1.0, and every readDataToLength:withTimeout: call in the file passed -1 as the timeout - GCDAsyncSocket never even creates a timer for timeout < 0, so the delegate method is never invoked at all. That's correct for ordinary post-handshake MTProto traffic - upstream deliberately moved timeout enforcement up to MTRequestMessageService request-level watchdog so a raw socket read timeout doesn't kill a slow-but-alive transfer. But that watchdog only arms once there's a queued MTRequest, i.e. only after the handshake has already completed. So it doesn't cover the SOCKS5 pre-auth handshake reads (MTTcpSocksReceiveHelloResponse..., MTTcpSocksLogin, MTTcpSocksRequest, MTTcpSocksReceiveAuthResponse, MTTcpSocksReceiveBindAddr...), which run before any MTRequest exists.

Fix

---

• Handshake reads SOCKS5 now time out after 15 seconds instead of waiting forever.
• If 15 seconds pass with no answer, the read now fails with an error instead of continuing to wait.
• Regular traffic after the handshake (encrypted MTProto data) stays unbounded, same as before MTRequestMessageService watchdog handles that.

Impact

---

A hang proxy now fails the handshake after 15s instead of hanging forever - app can report the error and retry/fall back instead of appearing frozen.

Note

---

Part of tracking issue: #182

Testing

---

• Tested on iOS Simulator 18.6/26.5
• Proxy that accepts TCP connections but never responds, confirm connection fails after ~15s instead of hanging indefinitely
• Normal proxy connect still works, no regression in handshake timing