node_device_udev: nodeStateShutdownPrepare: Disconnect the signals explicitly

The documentation of gobject signals reads:

"If you are connecting handlers to signals and using a GObject instance as your
signal handler user data, you should remember to pair calls to
g_signal_connect() with calls to g_signal_handler_disconnect() or
g_signal_handlers_disconnect_by_func(). While signal handlers are automatically
disconnected when the object emitting the signal is finalised..." [1]

This means that the signal handlers are automatically disconnected as soon as
the `priv->mdevCtlMonitors` are finalised/released by `udevEventDataDispose`.
But this also means that it's possible that new work is tried to be scheduled
for the workerpool by the `mdevctlEventHandleCallback` (main thread context)
even if the workerpool has already been stopped by `nodeStateShutdownWait`. To
fully understand this, it's important to know that the main loop of the main
thread is still running for some time even after `nodeStateShutdownPrepare` has
been called. Let's avoid this situation by explicitly disconnect the signals
during `nodeStateShutdownPrepare`, which is called in the main thread, so that
no new work is attempted to be scheduled for the worker pool.

[1] https://docs.gtk.org/gobject/signals.html#memory-management-of-signal-handlers

Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>

src/node_device/node_device_udev.c

@@ -2226,6 +2226,12 @@ nodeStateShutdownPrepare(void)
     if (!priv)
         return 0;
 
+    VIR_WITH_MUTEX_LOCK_GUARD(&priv->mdevctlLock) {
+        GList *tmp;
+        for (tmp = priv->mdevctlMonitors; tmp; tmp = tmp->next)
+            g_signal_handlers_disconnect_by_data(tmp->data, priv);
+    }
+
     VIR_WITH_OBJECT_LOCK_GUARD(priv) {
         if (priv->mdevctlTimeout != -1) {
             virEventRemoveTimeout(priv->mdevctlTimeout);