On failure, you get this:
no device found on drm_dp_aux5: Memory query failed: failed to write command
failed to get device after update: failed to wait for detach replug
The FWUPD_INSTALL_FLAG_FORCE flag has really unclear semantics, and ignoring a
file CRC, checksum or model ID should only be done when using fwupdtool actually
debugging a plugin or firmware parser.
Use the existing --force flag when we want a "gentle nudge" like reuploading
previously processed reports.
Print the sysfs path for devices deriving from FuUdevDevice, which also allows
us to use FU_UDEV_DEVICE_DEBUG without monkey-patching the plugins that also
define a device_class->to_string() vfunc.
Although they normally work, some failures have been reported in the field
related to the MST hub not responding in the MST plugin.
When these failures have occurred the dell_dock plugin also fails to
enumerate.
So rather than allow some people who don't have dell_dock compiled to
update their MST hub using synaptics_mst, perform ALL updates for
mst hub via dell_dock.
```
18:06:24:0324 FuPluginSynapticsMST no device found on drm_dp_aux1: VMM5331 inside Dell dock is only supported by dell_dock
```
This flag is used internally by plugins to indicate that they will
skip the phase of firmware installation that power cycles a device.
It is intended to be set by quirks or other environment settings.
Sometimes we only want to add the instance ID to get the quirk matches, and it
is confusing to see the "fake" IDs in the 'fwupdmgr get-devices' output.
If we say that the version format should be the same for the `version_lowest`
and the `version_bootloader` then it does not always make sense to set it at
the same time.
Moving the `version_format` to a standalone first-class property also means it
can be typically be set in the custom device `_init()` function, which means we
don't need to worry about *changing* ther version format as set by the USB and
UDev superclass helpers.
Synaptics versions are encoded as BCD, the largest version that will
ever be represented in this field is '99'.
Using 3 digits in this field has caused multiple problems in upgrades from
LVFS.
1. Devices are being upgraded when not necessary.
IE `5.3.10 > 5.3.010`
2. Device upgrades are deemed failures as follows:
```
BootTime=1571436076,
CompileVersion(com.redhat.efivar)=37,
CompileVersion(com.redhat.fwupdate)=12,
CompileVersion(org.freedesktop.fwupd)=1.3.2,
CompileVersion(org.freedesktop.gusb)=0.3.0,
CpuArchitecture=x86_64,
DistroId=fedora,
DistroVariant=workstation,
DistroVersion=32,
FirmwareId=1915,
Flags=4194346,
Guid=f15aa55c-9cd5-5942-85ae-a6bf8740b96c,
MachineId=97aa89528b88d9631867a4e20c68a5208124ef592e19d05f0c5e7d22bd4d7afb,
Plugin=synapticsmst,
RuntimeVersion(com.dell.libsmbios)=2.4,
RuntimeVersion(com.redhat.fwupdate)=12,
RuntimeVersion(org.freedesktop.appstream-glib)=0.7.14,
RuntimeVersion(org.freedesktop.fwupd)=1.3.2,
RuntimeVersion(org.kernel)=5.4.0-0.rc2.git2.1.fc32.x86_64,
UpdateError=device version not updated on success, 05.03.10 != 5.03.010,
UpdateState=failed,
VersionNew=05.03.10,
VersionOld=5.03.010
```
