hkuvpn v1.2.1

hkuvpn v1.2.1 — the field fixes

This release is what v1.2.0 should have been. Every item below was found
by running the client against the live HKU gateway for a whole day, and
every one of them made the client behave in a way that was hard to
diagnose. If you downloaded v1.2.0, take this one instead — the
release workflow that builds the archive did not exist yet when v1.2.0 was
tagged, so that archive carries the unfixed worker.

The fixes

• The system no longer crawls. The routing script registered the
  gateway's DNS servers on the tunnel adapter even though HKU pushes no
  split routes, so those resolvers were unreachable and the Windows DNS
  client waited on them for every name — opening a folder included. A
  resolver is now registered only when a route actually reaches it.

• Big transfers do not stall. OpenConnect sizes the tunnel adapter
  from the TCP channel's MTU (1271), which is larger than what the UDP
  channel carries (1246): packets in between were dropped, so a shell
  answered while a file transfer hung forever. The worker now caps the
  adapter at the DTLS MTU, read from the session log.

• A connect does not hang at "Connecting". The worker was losing a
  quarter of what the tunnel processes printed — the "Password:" and
  "Response:" prompts included — so the code dialog sometimes never
  appeared. The read now copies the bytes out before the next one is
  armed.

• The window stops claiming a session that is not there. A worker
  waiting for the MFA code beats its heart, so the app used to call that
  "connected", close the dialog and leave the session waiting forever.
  Only a session that reported its tunnel up counts as connected now, and
  a worker found waiting for a code is adopted with the dialog back.

• The UAC prompt can take as long as it takes. The connect attempt
  gave up after 20 seconds — but that clock started when you pressed
  Connect, and the UAC prompt in front of you may sit there longer. The
  clock now starts when the worker actually appears, and a worker that
  turns up while the app is idle is adopted rather than orphaned.

• TCP by default. HKU_DTLS shipped with DTLS/UDP on and TCP as the
  escape hatch, which is backwards for most users: cross-border links
  throttle UDP into heavy loss (41 percent on the link this was measured
  on), which stalls the session in confusing ways, while TCP only costs
  latency. Both editions now carry their data over TCP unless you ask for
  DTLS with HKU_DTLS=1 — worth it where the path is clean, inside Hong
  Kong for instance, where it cuts round-trips to about a quarter.

• Every setting says what it does when the pointer rests on it.

The Windows app

Same download as before: HKUVPN-windows-v1.2.1.zip — the app, the
worker it drives, the routing script and a START-HERE.md (also in
Chinese). Unpack it, run bin\get-tools.ps1 once as administrator, start
HKUVPN.exe.

Upgrade notes

Nothing to do. The Docker edition works exactly as before, and the
Windows launcher gained nothing either — the desktop app is a separate
thing that drives the same worker underneath it.

If you configured HKU_DTLS=0 by hand, it still means the same thing.
If you had no HKU_DTLS line at all, you now get TCP instead of DTLS.