thread-pool: Allow at least 1 thread in thread_pool_adjust_max_threads_to_work()

thread_pool_adjust_max_threads_to_work() is supposed to give each task its
own thread by setting the pool max thread count limit accordingly.

However, if there aren't any tasks currently in the pool the pool max
thread count will be set to 0, which will trigger an assertion failure
in thread_pool_set_max_threads() - because setting this value would
completely block the pool by not allowing it to process any submitted
tasks.

This also can happen if a task is submitted via
thread_pool_submit_immediate() to an empty pool but the task completes so
quickly that by the time this function calls
thread_pool_adjust_max_threads_to_work() the pool again has no unfinished
tasks in it.

Quoting from Maciej on reproducing this issue:

  It's difficult to reproduce in most setups.

  My main VFIO live migration setup never hit it for more than a year,
  other similar setup hit it recently 3 times.

  On the other hand, putting sleep(5) in the middle of
  thread_pool_submit_immediate() makes it reproduce nearly always for me.

Fix this by making sure that the pool is allowed to create at least 1
thread.

Fixes: b5aa74968b ("thread-pool: Implement generic (non-AIO) pool support")
Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Link: https://lore.kernel.org/r/b76c763f576b0fb8a35960a8e3c3da59701d2a74.1779390317.git.maciej.szmigiero@oracle.com
[peterx: added quote into commit message on reproduce details of the issue]
Signed-off-by: Peter Xu <peterx@redhat.com>

util/thread-pool.c

@@ -493,5 +493,5 @@ bool thread_pool_adjust_max_threads_to_work(ThreadPool *pool)
 {
     QEMU_LOCK_GUARD(&pool->cur_work_lock);
 
-    return thread_pool_set_max_threads(pool, pool->cur_work);
+    return thread_pool_set_max_threads(pool, MAX(pool->cur_work, 1));
 }