ProxyVolumeMonitor: Don't leak a GVfsDBusDaemon
In g_proxy_volume_monitor_register() we create a GVfsDBusDaemon object (which is also of type GDBusProxy) but never free it. This causes there to be a dangling reference to the singleton GDBusConnection object used by the GDBusProxy for the rest of the lifetime of a process that uses a gvfs function such as g_file_new_for_path(). With the recent changes I made to GLib[1], that extra reference leads to a warning after a 30 second delay in g_test_dbus_down().
So this commit frees the GVfsDBusDaemon object after it has served its purpose in g_proxy_volume_monitor_register(), which fixes the test failure I'm seeing in another project.
This is consistent with how we handle GDBusProxy objects in most of the rest of gvfs, but there are two places where they are leaked:
- in g_proxy_volume_monitor_constructor(), but that object appears to be intended to live forever, so it's unclear what should be done there
- in meta_tree_get_metadata_proxy(), but there the proxy is a static variable so it's unclear when it should be freed
If you try to reproduce this leak, note that if gio takes its "lazy loading" code path in g_io_modules_scan_all_in_directory_with_scope(), this g_proxy_volume_monitor_register() function may not be executed. So I had to change an if condition so that we would always call g_type_module_use(). That lazy loading only happened when I built and installed gvfs myself rather than using the distribution's package.