Qt should subscribe to dbus system tray and dbus menu service appearing/disappearing

Currently, Qt has isDBusTrayAvailable and isDBusGlobalMenuAvailable methods in qgenericunixthemes.cpp that write the result to static variables. That means that if app has been autostarted and at the time of the start dbus menu and dbus tray services weren't been launched yet, Qt app will stick to XEmbed tray or don't have tray icon at all, dbus menu won't work at all for sure. Even if app developer will subscribe via QDBusServiceWatcher to events, reconstructing QSystemTrayIcon/QMenubar won't help since these variables are static. In practice, it's really reproducible with Plasma and Qt applications that don't use Plasma's QPA (e.g. proprietray ones with their own Qt bundle, AppImages, static binaries and etc.). These applications have a blurry tray icon with a non-native context menu. Restart of these applications help, but do we want to live in a world where applications should be restarted to work properly?

I believe, Qt should subscribe to com.canonical.AppMenu.Registrar (for QMenuBar) and org.kde.StatusNotifierWatcher (for QSystemTrayIcon) service owner changes and initialize QDBusMenuBar/QDBusTrayIcon when services do appear and switch back to another backend when they do disappear. For QSystemTrayIcon it's also important to subscribe to StatusNotifierHostRegistered signal on org.kde.StatusNotifierWatcher service (e.g. Plasma register the service early, but it actually accepts requests only after StatusNotifierHostRegistered signal).

This is relevant from early Qt 5 versions and up to latest dev.