Issue title: Documentation: Malicious server
 Issue body: I am wondering what a hostile XPRA server could do to a XPRA client. Suppose you connect via XPRA to an infected machine. Is the client then safe? Under which circumstances could an attacker take over the client? What has been done to prevent such things? Things I can imagine is that an attacker exploits bugs in the decoder of the video signal or the audio signal that is decoded using Gstreamer. 

Maybe one could add a section about those questions to the documentation.

The reason why I am asking is because I am thinking to use XPRA for application isolation on a server to protect the clients. Also are there any recommendations for setting up something like this? If so, maybe we could also add them to the docs.

Peter
 Comments: 
 Comment 0: A lot of thought has been put into this exact question over the years.
The client is very safe by default and things can be done to tighten it up further.

To prevent DoS, we limit the number of packets being processed and how big they are.
(same for packet decompression)

Every major feature can be disabled and the code supporting it will not be loaded into tjackson@example.org.
(some other features can be changed to ask permission instead)

By default, we restrict the type of picture encodings that will be parsed.
So although the `python-pillow` library is capable of parsing almost every image format you can throw at it, before feeding it any data we will verify that the data given is one of the few formats we actually support. (ie: typically `png`, `webp`, `jpeg`)
And these formats are usually handled by a native Cython decoder anyway.
Which means that you would need to find an exploit in `libpng`, `libturbojpeg`, `libwebp` or `libavif` to take over the client. Not impossible, but this doesn't happen very often.

One could argue that the `h264`, `vp8` and `vp9` encodings are easier targets (perhaps), but one can always restrict the encodings using the `encodings=` option.

Audio is a different beast, and runs in its own subprocess.
There are so many codec combinations that security sensitive usage should consider turning off audio forwarding by default, or perhaps limiting the client to codecs that are battle hardened. ie: `--speaker-codec=mp3`. (anyone finding a vulnerability in the `mp3` decoder deserves a medal)

Xpra is being used regularly for isolation.
There are so many different things that can be done to tighten an installation and the configuration that this is far beyond the scope of this issue tracker / documentation.
 Comment 1: 
Yes, I can imagine that the options are quite numerous given all the configuration parameters. Nonetheless, I think it will be a big plus to describe that client hardening in a separate chapter in the documentation. It seems to me that this is one big difference compared to other projects as e.g., X2Go or so. Furthermore, for new users (like me) this would be a very helpful resource to get started.
 Comment 2: I don't know which x2go page you are referring to but the ones I found are quite superficial and do not even begin to touch the real fundamental issues that have affected it over the years.
As for adding this to xpra, feel free to start adding a new documentation page, perhaps here: https://github.com/Xpra-org/xpra/new/master/docs/Usage
 Comment 3: I have started something here: https://github.com/Xpra-org/xpra/blob/master/docs/Usage/Security.md
{'source': 'GithubIssues', 'repo_name_with_owner': 'Xpra-org/xpra', 'issue_id': 1262841984, 'repo_stars': 698.0}