KIO workers and the Qt5->Qt6 transition

[Nicolas Fella]

Hi,

this is a variant of the plugin problem outlined in
https://mail.kde.org/pipermail/kde-devel/2023-December/002234.html

TL;DR Qt6 can't load Qt5-based plugins and vice versa

This also affects KIO workers.

We have a number of sources of KIO worker plugins:

- KIO itself provides file, http, help, ftp, remote, and trash. Since
KIO is available from KF5 and KF6 we get builds of those for both Qt
versions. No problem here.

- kio-extras provides additional workers: sftp, mtp, smb, ... kio-extras
is available for KF5 and KF6, so no problem here.

- various kio-* modules, like kio-gdrive, kio-stash, kio-gopher. These
should be built for both Qts, which should generally be possible, modulo
some common files to be deconflicted

- "Applications" that ship a KIO worker as part of their offering.
Examples that come to my mind are KDE Connect that ships a kdeconnect
worker and bluedevil that ships the bluetooth and obexftp workers. These
project are generally not designed to be coinstallable. i.e. if I have
Qt6-based KDE Connect I can't use the kdeconnect worker from a KF5 app

The last case is the one giving me headaches. Possible options would be

- Ignore the problem and hope nobody misses some workers in some
applications

- Make sure all (relevant) workers are available for both Qts, adding
some complexity to the build, release, and packaging process

- Since KIO workers run out of process it should be technically feasible
to come up with a way to run KF5-based worker plugins from a KF6-based
app and vice versa. I have not tried to implement that though, and it
would require some non-trivial surgery on KIO internals