Bluetooth provider workaround for BlueZ/DBus timeouts
Context: !600 (comment 884500)
When bluetooth doesn't exist on the machine at all, QTConnectivity tries to communicate with Bluez via dbus and introduces a 30 odd second pause. That's not necessarily a problem in concept, however this blocks the main thread of KDEConnect, which also then blocks the main thread of Plasma on logon and causes tremendous delays and very broken behaviour.
For the life of me, I cannot find a way to do "is bluetooth ok" without QTConnect kicking off the dbus call so I think the only option is to thread off the startup of the providers so that pauses don't block the whole process.
I've just tested this here and my logon with bluetooth missing went from approx 35 seconds down to about 2.
Ready for input/feedback whenever people have time; in my testing at the moment it seems to completely break the behaviour of KDEConnect (i.e. things can't connect), I'm guessing this is something to do with the effect of wrapping everything in the QThread. I'll dig into that next and see if I can figure it out.
(cherry picked from commit bb146a76)
4beb8c65 Fixing hanging startup/logon when bluetooth is unavailable
Co-authored-by: Rob Emery kde@mintsoft.net