we can't just have an unlimited number of threads for flatpak transactions. it'd eventually cause excessive load on both CPU and network to the point where things will start misbehaving. we also run risk of exhausting other software limited resources such as file descriptors.
to resolve this problem we now treat the transactionthread as runnable and put it in a limited threadpool for concurrent execution. the new runnable has a finished signal that is emitted on every return from run() to match the QThread API.
concurrency is limited to no more than 4 runnables at a time. that should still be plenty concurrent while generally unexpected to exhaust the default 1024 file descriptor limit - an install transaction appears to weigh between 60 and 100 fds
other backends don't necessarily have this problem since they have daemons that do the work for us so we have way fewer open fds for them.