PR27323 debuginfod: improve query concurrency with grooming

Start using a second sqlite3 database connection for webapi query
servicing.  This allows much better concurrency when long-running
grooming operations are in progress.

No testsuite impact.  Grooming times are too short to try to hit with
concurrent requests.  OTOH the existing tests did show some
interesting regressions that needed fixing, like needing not to
dual-wield db and dbq when doing rpm-dwz-related lookups from during
scanning, and the way in which corrupted databases are reported.
These needed some automated invocations of gdb on the running
debuginfod binaries that just failed their testing, for in-situ
debugging.

Hand-tested for function on a huge 20GB index file.  Allowed webapi
queries to be run throughout random points of the grooming process,
including especially the long count(*) report loops before & after.

Signed-off-by: Frank Ch. Eigler <fche@redhat.com>
2 files changed