asynchronous feature initialization

[totaam]

Somewhat related to #4523.
We already do something similar to this for the keyboard: 7d344bc, except generic.
On the server side, we should be able to initialize subsystems when we get their specific data.
For backwards compatibility, we still need to send a full hello packet synchronously.
Maybe add a toggle to use the new "fast" startup?
Or we could abuse the challenge hello: pretend we expect authentication, which will send a partial hello - then we can figure out if asynchronous mode is supported by the server? (meh: this could make things slower with an extra roundtrip)

The server side is easier, we can just call parse_client_caps when we get the data.

xpra/xpra/server/source/stub_source_mixin.py

Line 46 in b7bdb02

def parse_client_caps(self, c: typedict) -> None:

Then get the caps:

xpra/xpra/server/source/stub_source_mixin.py

Line 51 in b7bdb02

def get_caps(self) -> dict[str, Any]:

And send them to the client.

[totaam]

The XPRA_BACKWARDS_COMPATIBLE=0 env var from 9c34212 (#4496) will help.

[totaam]

The subsystems that can benefit the most from this change are:

• audio: no need to block and wait for the initial audio probing subprocess to return
• printer: can be done leisurely in a thread
• webcam: hardware probing
• command: loading the xdg menus can take a very long time, so recent versions already use threading + a settings-change packet
• encoding: already threaded, just need to send the updated encodings to the client?

---

Until the initialization completes, the client sources will have to assume that the subsystem will be available, and in some cases it will not be. (ie: audio probing could find that there are no codecs available)

---

Client side, a new initialization function must be added.
Instead of doing both option parsing and initialization in the same place.

Examples:

xpra/xpra/client/subsystem/audio.py

Line 102 in 0eee0f0

def init(self, opts) -> None:

Calls:

xpra/xpra/client/subsystem/audio.py

Line 131 in 0eee0f0

self.audio_properties = query_audio()

And:

xpra/xpra/client/subsystem/encoding.py

Line 107 in 0eee0f0

def init(self, opts) -> None:

Calls:

xpra/xpra/client/subsystem/encoding.py

Lines 133 to 135 in 0eee0f0

	vh = getVideoHelper()
	vh.set_modules(video_decoders=opts.video_decoders, csc_modules=opts.csc_modules)
	vh.init()

Mmap should be able to only create an mmap area if the server has mmap enabled.
Anything that can load implementation from a backend (ie: notifications, clipboard, tray) can do it after hello.

[totaam]

Lots of unforeseen problems! Just for audio!

• more calls need to be made from the UI thread (ie: pulseaudio query accesses the X11 display)
• the system tray was validating settings after the handshake, which is now too early
• av-sync still needs splitting into a separate module to match the server side

So in the end, I went with a less generic solution than planned, because the generic solution did not make sense for the few subsystems that need it.

---

The new asynchronous audio feature can be more easily tested by adding delays in the audio probing with XPRA_AUDIO_QUERY_SLEEP=10 (in seconds)

[totaam]

This will do for now.

The client feels faster to connect now, at least when running with XPRA_BACKWARDS_COMPATIBLE=0.