Analyse and resolve side effects resulting in drops of connectivity in Qt Quick apps when network connections change

There was an internal discussion related to a customer project in which various side effects were observed on the app (Qt Quick) level when the underlying system (embedded Linux) stack was losing network connections, for example when WiFi network drops I posting a short summary of this here.

That given customer now uses a workaround, but I wish these effects would be analysed further so that we will improve the Qt Network stack for all users. Yes, I'm aware that a few aspects are specific to the use of Linux on embedded systems, but I did see evidence that potential improvement cannot reside in generic Qt code.

Initially, the connectivity was restored by resetting QNetworkAccessCache after a connection drop. It seems to be related to QTBUG-133938 .

It was also mentioned that on embedded Linux, it is hard for Qt to discover connection drops for various reasons, and using QNetworkConnectionMonitor did not help (It's either using NetworkManager or glib, but glib doesn't support the detection of the connectivity change, it only test it at startup).

It also turned out that QML builds up an own cache QQuickPixmapCache and the app get stuck there on the connection drop.

QNetworkAccessManager can be used clear the connection cache. While that works. The QQmlEngine only allows to retrieve the primary one for the main thread using a getter. But there is second one dedicated to the image/pixmap thread. This one also needs to be reset.
The only way to be able to reset the cache completely is register a QNetworkAccessManagerFactory for the QQmlEngine and call clearConnectionCache on all instances (in the correct thread).
Having two QNetworkAccessManager instances is also against what the documenation says, where it states that usually only a single instance is needed at all.

(please edit / correct if needed)