Serial tasks are intended to be executed initially and in their own
workerpool, to prevent interference with other tasks executed in
parallel. Currently, the number of workers is fixed at either one or
two, depending on whether the given task creates additional subtasks.
However, this is suboptimal in case of tasks creating a subtask for
each node in the cluster (e.g., to capture profiling/tracing data),
as the collection on separate nodes may be performed in parallel to
speed-up the overall execution time. Hence, let's respect the worker
count parameter in this case as well, given that the overall logic
is already ensuring that we'll wait for their completion before
moving to the next task.

Signed-off-by: Marco Iorio <marco.iorio@isovalent.com>

This reverts commit fbcd8ee.

Now that the serial task execution logic has been modified to respect
the configured worker count, hence speeding up the execution time,
let's move again the collection of profiling data to the set of serial
tasks, to prevent it from being impacted by the other sysdump collection
tasks.

Reporting the message of the original commit below, for convenience.

Move the collection of profiling data to the list of serial tasks that
are executed at the beginning, to prevent it from being impacted by the
other sysdump collection tasks. Indeed, many bugtool operations invoke
the Cilium API (potentially performing expensive operations), hence
impacting the pprof results. Differently, the collection of the cilium
operator and clustermesh-apiserver profiling data is not moved, as not
expected to be impacted by the parallel tasks.

Signed-off-by: Marco Iorio <marco.iorio@isovalent.com>