launcher: start the protocol so the client reads the server's replies

[andrewachen]

The GTK launcher's built-in connection path (do_start_xpra_client) calls make_protocol() but never calls protocol.start().

make_protocol() builds the SocketProtocol and schedules send_hello(), but the network read thread is only started by protocol.start() — which the command-line client does explicitly (xpra/scripts/main.py) while the launcher does not.

As a result, a client started from the GTK launcher sends its hello but never reads anything back: the connection reports "network connection established" and then times out with "0 packets received" on every transport (tcp, ssl, quic).

This regressed in 25d6e80, which split make_protocol() out of setup_connection() and moved the start() responsibility to the callers; the command-line callers were updated but the launcher was missed.

The fix calls protocol.start() after make_protocol(), matching the command-line client. Verified on Windows (GTK launcher, built-in connect): with this change the launcher connects over both tcp and quic; without it the client hangs after "network connection established".

Sponsored-By: Netflix

[totaam]

Already done in 0cff445 / da3fa87, details in #4938

[andrewachen]

Thanks!

[andrewachen]

@totaam thanks for the quick triage. #4938 does address the same underlying symptom (the protocol never gets started → 0 packets received), but I think it fixes a different caller and the GTK launcher path is still affected.

All of the #4938 commits touch run_remote_server (xpra/scripts/main.py) and socket_handler.py:

• master: da3fa8745e, b32003f8f1 (+ 0cff4450 for the idempotent start())
• v6.5.x: e7dc2a1197, c911a3f62a

None of them touch xpra/client/gtk3/launcher.py. The GTK launcher's built-in connect doesn't go through run_remote_server — it goes through do_start_xpra_client, which on both current master (6c6e81f46e) and v6.5.x (deeeedcc88) still does:

self.client.make_protocol(conn)
self.set_info_text("Network connection established")

i.e. no protocol.start(). The regular GTK client's run() chain doesn't start it either (only the command client's run() does, in command.py). So launching a session from the GTK launcher reproduces the exact #4938 symptom — hello sent, then 0 packets received and an idle timeout after "network connection established" — over tcp, ssl and quic.

This PR's one-liner calls protocol.start() after make_protocol() in do_start_xpra_client, matching what run_remote_server now does. Verified on Windows over both tcp and quic: without it the launcher hangs; with it, it connects.

Would you reconsider this PR (or fold the launcher fix into #4938)? Happy to rebase onto master/v6.5.x, or rework it to lean on the idempotent start() from 0cff4450, whichever you prefer.

[totaam]

My bad, I thought that the earlier commit had fixed both!