This should likely be done in the other updating functions of the
`Database` class as well to avoid indexes and actual data appearing
inconsistent during the write operations.
When adding a new database when reloading the config at runtime the
architecture must be passed when creating the database. Otherwise we end up
with the new database sharing the internal storage with the x86_64 database
which leads to very confusing behavior.
* Avoid using buildDate of PackageInfo in favor of the same field in
PackageBase
* PackageInfo::buildDate should be removed on the next breaking change
* Do not really use the deprecated attribute because it is still used by
(de)serialization code until it is removed for good
* Break backwards compatibility
* Allow to deserialize only base-data of packages and build
actions to potentially speed up showing tables
* Speed up package search in many cases by only deserializing
base-data (unless details are actually wanted)
* Avoid creation of map with all archive contents; instead parse packages
while walking though the archive
* Avoid instantiation of std::string in come cases (using std::string_view)
* Reuse libarchive's archive entry when walking though archive
* Use visitor-based database parser in all places to avoid intermediate big
array with all package objects
Especially when enabling files DBs it is quite problematic to store all
package objects of a database within one big array. This change avoids the
array and instead adds the packages directly. The disadvantage is that
clearing the database isn't as simple anymore.
* Avoid keeping list of all packages in memory by pushing each package
directly to the JSON array
* Avoid check for database before pushing each package; do it only before
reaching the next database
* Remove no longer required functions
* Only lock the config for writing the reloading the config file
* Make sure all write operations to the database acquire an "update mutex"
to ensure only one write operation happens at a time
* Do *not* acquire any additional locks when reading from a database as it
should be safe to do so even when a write operation happens because
* LMDB read and write transactions can happen at the same time
* The package cache has its own mutex anyways
* Write ops to the package cache try to lock the "update mutex" to
prevent writing "old" data to the cache during updates
* Make "lastUpdate" atomic to avoid locking the config when accessing it
It is about
```
return result_type{ storageEntry.id, storageEntry.ref.relatedStorage };
```
but it isn't clear why the compiler thinks there's a problem.
