PR28339: debuginfod: fix groom/scan race condition on just-emptied queue

PR28339: debuginfod: fix groom/scan race condition on just-emptied queue

debuginfod's scan and groom operations (thread_main_scanner,
thread_main_fts_source_paths) are intended to be mutually exclusive,
as a substitute for more complicated sql transaction batching.  (This
is because scanning / grooming involves inserting or deleting data
from multiple related tables.)

The workq class that governs this in debuginfod.cxx has a problem: if
the workq just becomes empty, its sole entry pulled by a scanner
thread in response to a wait_front(), an 'idler' groomer thread is
ALSO permitted to run, because there is no indication as to when the
scanner thread operation finishes, only when it starts.

Extending the workq with a counter ("fronters") to track any active
scanning activity (even if the workq is empty) lets us block idlers
groomers a little longer.

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