See https://github.com/hughsie/fwupd/issues/110

If this is not done the origin from the last file that was read (which might be
from Fedora, for instance) will be used. This isn't hugely important but can
give misleading and confusing unique-id's in gnome-software.

The meson build system does not let you choose the output name of the resource.

This was added for cosmetic reasons, and including the version makes the
generated html documentation change every release even if there were no API
changes.

We've been really bad at keeping these up to date, so just drop them.

These can be nuked at any time by users, so don't rely on the package manager
or installer to create these for us.

Packagers should still enable it so that tracking lost memory
in plugins is possible, but on some distros some archs don't
have valgrind available which would otherwise prevent fwupd
from running.

This is as problem currently for Debian unstable where some
archs valgrind fails to compile.

Even with the other changes this is still required for me on Fedora 25.

Without this patch, unloading the module means we can't resolve the symbols
where the memory was leaked.

commit 99b317d4 introduced much
more strict confinement. This actually caused some regressions
though.

commit 3c54edb1 tried to fix
one of the problems, but didn't cover the rest.

The actual changes:
- Drop PrivateUsers=yes
  This is causing crashes when initializing libsmbios
  Presumably it's related to accessing memory.
- Add back in NoNewPrivileges
  This hasn't caused any crashes for libsmbios for me.
- Remove ProtectKernelTunables
  This is needed to access /sys for the dcdbas kernel
  module used by libsmbios.  Calls fail without it
- Add ReadWritePaths=/var/lib/fwupd /boot/efi
  The refresh function was failing the first time due to
  ProtectSystem=full being in effect and /var/lib/fwupd
  being read only
  Flashing UEFI capsules was failing due to being unable
  to write to /boot/efi/EFI/$(EFIDIR)/fw/

For some reason NoNewPrivileges=yes causes the process to be killed when run on
hardware specifically from Dell. I can reliably reproduce this on my XPS 13 and
I assume it's something to do with libsmbios.

As found in https://github.com/dell/libsmbios/pull/13
there are some errors with libsmbios error paths.

These need to be fixed in libsmbios, but at least avoid
running this code on those systems (and crashing fwupd).

This reverts commit 0e8f5d93.

This is in the same vane as 4da67515, it allows linking with
an older efivar.

*This* is why we were getting confused.