Qt VNC Server - Initial version of the support for Remote UI

What is the benefit? Why is this valuable?

This task outlines the scope of the first implementation of Remote UI. It exists at the time of writing as an internal prototype but should be published upstream soon.

What are the common use cases?

Use cases mentioned in the epic remain valid. There are the following specifics though:

• The code of an application must be modified to enable this feature
• Only QML-based UIs are supported
• Only standard native RFB clients or browser plugins can be used on the client-side. Writing a custom native client based on Qt is technically possible, but is not provided as a delivery from Qt

Technical Information 

References with numbers in round brackets point to topics listed in the epic of this task.

• The current solution supports Qt Quick apps. There is no Qt C++ support (8) (9)
• Any "stand-alone app" using the new "projection Item" in its code is enabled for projection (1)
• In order to share the whole app w/o chaging its code, the app should be running in a Wayland compositor which includes the new projection Item
• Application code must be changed (2) (1)
• Developed on Linux. To be tested/verified on other desktops and embedded Linux (3) (4)
• Enabled by adding the new "projection Item" to the "app" code. All items in the hierarchy underneath are included in remoting (1) (8) (9)
• When this "projection Item" is added to a QtWayland-based compositor, a projection of any app UI running on this compositor is possible (6)
• Compliant with mandatory features in RFB (https://datatracker.ietf.org/doc/html/rfc6143) and so should work with basically any RFB or VNC client (11)
• Multiple top-level windows can be projected as well, but on the level how Wayland "understands" it (12)
• Multiple clients (viewers) can be connected and interact with the projected app (13)
• There is an item property where you can check if there is an active connection (15). This can be used to implement an indicator that a projection is ongoing
• Input can be disabled (14)
• Standard keyboard and mouse are supported, multi-touch is not supported (16)
• A dedicated PIN/Password protection is supported via a property. Plus, there are options in the RFB standard which are used for encryption of the traffic., but it is rather an "idiot" protection (17) 
• Basic logging is available but had to be converted to cover (18)
• Multithreaded, plus if the traffic is slow, the local performance will not be impacted
• Still, there is a load for each connected client on the server-side
• If a client is not connected, there is no performance impact
• Planned to be available as TP in 6.4
• Works are ongoing to backported it to Qt5, but it will be on a "need-to-get basis" and not available as a new feature on Qt5