fixes FTBFS in Debian:
https://buildd.debian.org/status/fetch.php?pkg=fwupd&arch=armhf&ver=1.5.7-1&stamp=1614100547&raw=0

Use a Fu prefix for source objects and files and use @self.

No logic changes.

Signed-off-by: Richard Hughes <richard@hughsie.com>

If the user explicitly specifies the device-id then we do not do the front-end
filtering. If the device detaches without being able to attach then the hardware
could be left in the bootloader state.

See https://github.com/fwupd/fwupd/issues/2926#issuecomment-784234180

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.

If any flags are set in the baseclass (e.g. FuDevice) then incorporating with
a FuUdevDevice or FuUefiDevice is not going to merge the flags.

We can enable this once we have a real plugin that actually depends on it.

* rts54hub: Optimized rtd21xx ISP flow

Ignore the request if _all_ the new flags are already set, not just any of them.

Although glibc calls this when memory gets low automatically, we can invoke it
manually when we've loaded all plugins and coldplugged all devices.

This has no effect when using proper heap benchmarks like massif, but random
Reddit users just looking at the RSS column in an 'easy-to-use memory profiler'
will see a much lower numbers.

Where this feature might actually be useful is after a libxmlb metadata rebuild
where we dirtied a lot of heap just parsing XML.

The current approach of adding SBAT metadata after linking is creating
an image that is badly formed in 2 ways:

 * The SBAT section's file offset and size are not a multiple of the
   file alignment.

 * The SBAT section has a virtual address of zero. EDK2 loads the header
   here, and so it gets rejected.

This changes the approach to match shim, where an object file is
created with a .sbat section and then the linker takes care of placing
the section at a more appropriate virtual address.

See https://github.com/vathpela/gnu-efi/pull/14 for the section addition.

This is typically when the OEM is using the reference hardware design.

Prevent updates, as there might be a new bug introduced in the reference
firmware that only manifests on one OEM's product. It's up to the OEM to do the
testing and validation.

We need something to tie it back to a physical device model if it's using a
reference firmware and we want to update it.

Bare skeleton for what will be the Bluez backend and the base bluetooth
device class.

This should be dropped at some point hopefully when the new
docker release has landed.
See: https://github.com/actions/virtual-environments/issues/2658
Fixes: #2894

Also split out the firmware parsing to an object so we can check the firmware
using firmware-parse and also fuzz it.

See also: https://github.com/fwupd/fwupd/issues/1665

Fixes https://github.com/fwupd/fwupd/issues/2916

Let these get turned on no matter what we change in daemon.conf

some of these might not be present if the containers got out of
sync.  it will be a no-op at worst.

See https://github.com/rhboot/shim/blob/main/SBAT.md

Fixes the regression introduced in fde4b167

This allows a device subclass to call the parent method after doing an initial
action, or even deliberately not call the *generic* parent method at all.

It also simplifies the plugins; you no longer have to remember what the plugin
is deriving from and accidentally clobber the wrong superclass method.