Provide a device instance builder that allows plugins to easily
create multiple instance IDs based on parent attributes.
Also fix a lot of the instance ID orders, so that we add more generic
IDs first, and more specific IDs after.
I assume at some point we forgot to remove it when converting an object
from FINAL to DERIVABLE and the anti-pattern just got copied around the
codebase...
Until gi-docgen is declared stable support either of them.
This effectively means that hand builds and CI builds will use
gi-docgen, but distro builds use gtk-doc-tools.
NOTE that currently this is implemented for GATT characteristics only,
but can be extended to other types of objects.
Listening for property changes in a bluez characteristic requires a
long-lived connection or proxy, so this also refactors bluez device
UUIDs into a simple object that keeps the path, the proxy and the signal
id in case a callback is registered for this UUID.
An additional advantage of this is that fwupd no longer creates a
throwaway proxy object for every read and write UUID operation.
It is far too easy to forget to set FWUPD_DEVICE_FLAG_NO_GUID_MATCHING for new
plugins, and without it it all works really well *until* a user has two devices
of the same type installed at the same time and then one 'disappears' for hard
to explain reasons. Typically we only need it for replug anyway!
Explicitly opt-in to this rarely-required behaviour, with the default to just
use the physical and logical IDs. Also document the update behavior for each
plugin to explain why the flag is being used.
This allows you to have two identical Unifying plugged in without one of them
being hidden from the user, at the same time allowing a HIDRAW<->USB transition
when going to and from bootloader and runtime modes.
This removes the workaround added in 99eb3f06b6.
Fixes https://github.com/fwupd/fwupd/issues/2915
References to opt_variant and val_variant are sunk in a subsequent
variant creation and consumed by g_dbus_proxy_call_sync. They don't need
to be freed in this context.
