SOCKS5 proxy: connecting hangs / never recovers after a settings change

[mvsrcdst]

Problem

---

Configuring a SOCKS5 proxy and trying to log in / connect would spin
forever with no error, no timeout, nothing actionable in the UI. Digging
into it turned into finding three independent, unrelated bugs on the same
code path. Each one hiding behind the others, which is why it felt
"randomly broken" rather than consistently broken in one obvious way.

Investigation

---

1. First fix attempt (IPv6): noticed MTTcpConnection always hardcoded
   the SOCKS5 CONNECT destination as IPv4 and never checked whether
   inet_aton actually succeeded. For a DC scheme with an IPv6 address,
   that silently sends garbage to the proxy. Fixed the address-type
   detection - proxy still hung. (Note: official upstream
   TelegramMessenger/Telegram-iOS has an open PR, Fix incorrect proxy request address type for IPv6 TelegramMessenger/Telegram-iOS#735, addressing this
   same underlying IPv4/IPv6 detection gap, still unmerged as of this
   writing. Our fix is independent but conceptually similar.)
2. Second fix attempt (timeout): the SOCKS5 handshake reads had no
   read-timeout at the socket level (shouldTimeoutReadWithTag returned
   -1.0 unconditionally, i.e. "never time out"). This mostly doesn't
   matter for a first-time connection (an unrelated discovery-layer
   watchdog already bounds that case to ~5s), but it does matter when
   reconnecting via an already-cached scheme after a previously-working
   proxy stops responding mid-session. That path has no other timeout at
   all and can hang indefinitely. Bounded just that pre-auth handshake
   phase explicitly but this still required an app restart to actually
   pick up a corrected proxy configuration mid-session.
3. Third fix (reactivity): Account (post-login) already reactively
   picks up SharedDataKeys.proxySettings changes and updates the live
   MTProto network environment. UnauthorizedAccount (pre-login) had no
   equivalent, proxy settings picked up at init time were effectively
   frozen for the rest of the login flow. Added the same subscription.

Three independent bugs, three independent PRs

---

None of these three fixes touch the same code paths as each other, so
they can be reviewed/merged independently and in any order. One important
caveat for testing: the reactivity fix alone will not visibly resolve
end-to-end connectivity if the other two aren't also present it only
fixes "new settings aren't picked up," not the underlying connection
failure modes. All three failure points sit on the same user flow, so a
real-world "proxy just doesn't work" report could be hitting any one of
them (or several at once), which is exactly why this took three separate
investigations to fully resolve rather than looking like one bug from the
start.

• MtProtoKit: fix SOCKS5 proxy IPv6 connect sent garbage address #179
• MtProtoKit: fix pre-auth handshake reads could hang forever #181
• Proxy: fix proxy settings not reactively applied in UnauthorizedAccount #180