Only meant to be run from schedule pipelines, since there is a
rate limit for coverity.

Add a new container to perform coverity analysis, i.e. it fetches
the coverity distribution. Add a new coverity.sh script to actually
perform the analysis and upload the results.

Add a new test for `bolt_str_parse_as_uint` based on the existing
tests for `parse_as_xxx`.

Add a new helper to parse a string as unsigned integer (uint).
Internally uses the 64 bit based uint64 parse method and then
checks the parsed value fits into an unsigned integer.

For both, parse_uint{32, 64}, check that `errno` is properly set.

The `bolt_str_parse_as_uint32` method uses the uint64 based method
to parse the string and then afterwards checks for the parsed
value overflows an uint32. In that case also set the errno value,
to be consistent with the uint64 parse method.

The value we are checking is a signed 'int', so use the proper
comparison function, i.e. `g_assert_cmpint`.

If codespell is available, as it should be in the Fedora container,
run in on the source.

Can then be used by docker-build.sh to spell check the source.

Fix all spelling mistakes uncovered by codespell.

This makes codepsell happy without using a German dict.

Fedora 30 is actually EOL already. Use the current stable (F32).

Check that if bolt_domain_can_delete returns FALSE, the store does
indeed refuse to delete the domain.

Use the new bolt_domain_can_delete function to check if a domain
can be safely deleted before doing so. In the case it is not
safe to delete the domain, the bolt_store_del_domain method will
now return FALSE and propagate the error from domain_can_delete.

Check that if a domain has journal entries, bolt_domain_can_delete
indeed returns FALSE, and TRUE otherwise.
This code modifies the original test to use the original domain
object 'd1' to delete the domain instead of the object that was
fetched from the store. This is so that there are not two objects
referring to the domain.

Add a new method, bolt_domain_can_delete, which can be used to
check if a domain can safely be deleted without the loss of data.
Currently, the only case where this can happen if the boot acl
journal for the domain has entries.
The function returns FALSE and sets and GError accordingly in
case it is not safe to delete the domain.

Check that if we remove a domain, its journal gets removed as well.

Helper to check if a journal of a give type and name exists in the
store. Does not check if the specified journal has entries, i.e.
an empty journal does exist. :)

When the domain is remove from the store, which means that a
previously set "store" member will be set to NULL, also remove
the journal.

We need to have the fresh property set to false after put_diff is
called.

If all goes well and we replaced the journal with a new one, its
freshness needs to be set to FALSE, but was not. Fix that using
the new setter.

Add a setter method that will also emit the property notification.

Better separate the cleanup of an existing associated store from
referencing and setting up the new store and journal. This makes
it easier to follow and prepares for a new helper function to
remove the log (if empty).

Including opening and deleting the journal.

Add a new method to delete a journal of a given type and name.

Instead of doing it all directly in set_property, do it in a
separate function. No change to the logic itself.

Not much to see here. I do make typos. A lot. And David is not
here to check them. So I blame him, really.

Instead of using a construct continuing the loop in the case
that a device is not a thunderbolt device, just do the one
desired action if it is one.

Just be a bit more PEP-8 compliant.

On integrated TBT (like ICL/TGL) the UUID of the controller is not
stable, i.e. it changes between reboots. We therefore must not be
saving the domain.

The bolt daemon uses the uuid of the host controller, i.e. the
thunderbolt switch, to uniquely identify the domain across
reboots. The main reason for this was the boot acl, which can
change in the absence of the domain: in older tbt hardware, the
controller was powered in hardware when no device was attached.
If a user then wanted to remove a device from the controller,
that needed to be recorded and synced back to the boot acl
when the controller later became available again.

All this relies on the fact that the uuid of the controller is
stable, i.e. does not change across reboots. This sadly, is not
true for integrated TBT, like e.g. on ice lake (ICL) and tiger
lake (TGL).

In the manager, the stability of the domain's uuid is now
detected via the PCI id of the native host interface. If it is
in fact not stable, or if the PCI id is unknown, the domain will
not be stored. As a result, removing devices from the boot acl
while the controller is offline, will not properly be synced
to the controller. Since modern controllers are actually not
powered down, but use runtime PM, i.e. they go to D3 cold state,
this should indeed not matter much. Additionally, modern systems
use the IOMMU to secure device access and there the firmware can
and will indeed authorize the device during boot. Therefore the
boot acl becomes less important, and there seems indeed to be no
boot acl entries slots on ICL even.

Add the native host interface (NHI) udev device as a parent of the
thunderbolt domain for both, the device mock tree and the simple
add_host_domain function. The NHI is a PCI device, which bolt will
use to determine certain thunderbolt functionality, i.e. if the
uuid of the controller is stable.

Overwrite the disconnect method in TbDevice and reset the 'key' and
'authorized' attributes there, instead of conditional checks in the
base class.

Check well known stable and unstable cases and also check the
error case, i.e. asking for information about an unknown id.

Add a table that contains the information for which native host
interface (NHI), identified via their PCI ids, the uuid of the
associated host / switch device is "stable", i.e. does not change
across reboots.

When the domain gets exported, also log the detailed domain data,
via LOG_DOM ().

Extract the code that stores the domain, together with the error
checking path, into its own small helper function.
This is mostly to prepare for conditional storing of domains, in
the case when their uuid is not stable across reboots.

In handle_udev_device_added (), if the device creation failed,
show the sysfs path, so it is easy to identify the underlying
udev device.

Now that every domain has an NHI PCI device as a parent, check that
bolt_sysfs_nhi_id_for_domain works correctly.