There are two reasons for this. First is that GKeyFile is quite inefficient,
using a large amount of heap memory when loading. Given we don't actually use
the merge and replace functionality of GKeyFile and we only need line-by-line
access we can parse this ourselves and reduce the peak RSS considerably.
This also accidentally fixes another bug. Moving from multiple quirk files to
a single builtin.quirk meant that multiple subsystem plugins were deduped --
which isn't really what we wanted. For example, this now works:
[MEI]
Plugin = one
[MEI]
Plugin = two
This allows us to be more specific when matching devices, and also means we get
more attributes 'for free' from the FuUdevDevice->probe().
This would allow us to have multiple device GTypes handling multiple MEI
interfaces in the same plugin., for instance, PTHI and MKHI.
The slight fly in the ointment is that the kernel does not set the 'dev' for
the mei_me devices, but it's always going to be just /dev/mei0, so hardcode it.
fwupd does not know if the firmware is signed or unsigned unless
the Quectel secureboot commands set this flag. Assume that the firmware
is unsigned by default, which is the case for most firmware unless they
have they support the secureboot AT commands. If that's the case, the
right flag will be set anyway.
The daemon wants to auto-add the parent relationship from the analogix device
to the VLI device automatically, which is arguably more correct anyway.
No behaviour change, but the tree output in fwupdmgr will be reversed now.
A harmless error shows up in debian packages at build time:
```
dpkg-shlibdeps: warning: cannot find library libfwupdplugin.so needed by debian/fwupd/usr/lib/x86_64-linux-gnu/fwupd-1.8.6/libfu_plugin_flashrom.so (ELF format: 'elf64-x86-64' abi: '0201003e00000000'; RPATH: '')
```
This doesn't cause a functional problem because libfwupdplugin has already
been loaded by the daemon by the time these libraries are loaded.
In case the `dpkg-shlibdeps` checker becomes more stringent in the future
fix the warning.
When I replaced the regex with a fu_strtoull() in bb548f15 I missed that the
regex looked at the 2nd-to-last sysfs path element, e.g. the i2c bus number for
/sys/devices/pci0000:00/0000:00:15.2/i2c_designware.1/i2c-1/i2c-1AF80175:00 is
actually '1'.
This fixes enumerating the parade-lspcon on a Puff ChromeBox.
