afsql: allocate locks/condvars at startup

Instead of doing this for all start_thread/stop_thread pairs, allocate
them once to avoid churn.
Revert "afsql: another reset_parallel_push workaround"

This reverts commit e2ab5e690e0f28ebc3a2829817c5d4deb31783c7.
afsql: don't use a separate lock for protecting self->queue

Instead of relying on db_thread_mutex to protect LogQueue from changes
in multiple threads, rely on its internal locking. db_thread_mutex
will only be used for protecting SQL control variables and
nothing else.

Also, migrate to the use the log_queue_check_items() API instead of
peeking at the queue length and the internal set_parallel_push() API.

Signed-off-by: Balazs Scheidler <bazsi@balabit.hu>
afsql: make mutex lock-unlock pairs symmetric

The lock will be released in the middle of the loop, except, when the
transaction commit fails, but in that case, it's enough to release it
right before continuing.

References: bugzilla #29996
logqueue: remove log_queue_assert_output_thread()

When explicit-commits is in effect, SQL destination attempts to commit
the INSERT SQL commands when the number of uncommitted inserts reaches
the limit set by flush_lines. However, when the input queue of the SQL
desintation becomes empty, we do not want uncommitted INSERT commands
to hang in the air, so we register a callback to be notified when new
log messages become available and commit the last batch of them,
regardless of flush_lines settings. When this happens, then the implicit
condition log_queue_assert_output_thread() depended upon cannot be
satisfied, and not because of a programming mistake.

We could work around this limitation of that assertion, but the thing
is that this assertion is not very clean, and though it had caught a lot
of programming errors in the past, it may generate false positives in
case of destinations like SQL (and because of the lack of proper locking
around it, it may miss some real problems).

Long story short, we decided to remove it entirely, while ensuring that
all the methods of logqueue-fifo that assume to be running in the output
thread of simple log destinations are documented.

References: bugzilla #29996