Add a possibility to:

1. Define "Timeout(int msecs)" item that could be inserted into a Group. Since now only Done and Error results of Task execution are possible, we should add a new Timeout type as next possible result.

2. Add new result type Canceled, issued when TaskTree::stop() was invoked, or when some task got aborted because of a failure of other task and stopped by a parent Group because of its workflow policy. May be diverged into two possibilities: CanceledByUser (TaskTree::stop() was executed) and CanceledByTaskTree (automatically canceled by TaskTree according to workflow policy). TODO: should be confronted with Group's workflow policy - maybe the latter needs to have more values?

3. Define "Repeat(int count)" item that could be inserted into a Group. This would repeat the execution of the whole group "count" times in a row (sequentially).

4. Define "Delay(int msecs)" item that could be inserted into a Group. Similar to Timeout(int msecs), but this element could define its custom done handler

5. Make it possible to start next (or nested) task only after the previous (parent) already started (or later, when it already replied it's ready). For this we would need to add TaskInterface::started() signal (or other, like: readyToStartSubTasks()). Nesting tasks in this case is better, since stopping it would preserve the right order automatically. TaskInterface::started() signal seems enough - other cases (when ready after task replied) are very specific to the particular task and providing a new adapter with delayed emission of started() signal would be enough (similar to how it's done in case of master ssh process). Whenever a parent task finishes, all children should be stopped automatically . When the last child finishes, should parent be automatically finished .

6. Add fine-grained progress reporting for all task types. Maybe task setup handler could accept additional argument, similar to QPromise with regards to progress reporting?

The 1. and 3. could serve for stress test implementation inside AutoTest plugin.

Side note: when having 1. and 3., a TrafficLight example (similar to state machine in Qt) could be implemented using TaskTree.

Some other maintenance remarks:

A) Unify done and error handlers (like QtcProcess unified finished() and errorOccurred() signals into one common done() signal):

• task's done and error handlers (leave just done handler with additional, not mandatory argument - may be a struct)
• OnGroupDone and OnGroupError handers (leave just OnGroupDone with additional, not mandatory argument - same as in case of task's done handler)
• TaskTree::done() and TaskTree::errorOccurred() signals (leave just done() signal with additional argument - same as in case of OnGroupDone handler).

Rationale:

• It's often case that user code connects to both TaskTree::done() and TaskTree::errorOccurred() signals and the implementation is nearly the same.
• It's more clear that the task tree is already finished when there is only one done() signal. When having errorOccurred() in addition it's not clear that done() handler won't be called afterwards.

B) Rename TaskItem into GroupItem. (Rename internal TaskNode and TaskContainer accordingly).

Rationale: Not all classes derived from TaskItem are tasks, but the common denominator is that all may be placed inside a group: thus GroupItem sounds more appropriate.

C) Rename CustomTask into Task

Rationale: Every final task is derived from CustomTask, so the Task name is general enough and more appropriate here. Note: don't confuse with ProjectExplorer::Task (and don't clash when both ProjectExplorer and Utils::Tasking namespaces are used together):

• The ProjectExplorer::Task may be a subject to rename, as it's rather a simple data container, not a task per se. The name "Task" in too general in this context and shouldn't be reserved for this specific usage.
• Could be renamed to e.g. TaskHubData
• Currently ~880 usages of "Task", however, most refers to it's enum values, like Task::Error (325 usages), Task::Warning (180 usages), Task::Unknown (60 usages) or Task::TaskType itself (140 usages) - in total about 700 usages of "Task" name are because of this enum. This enum could be potentially moved outside.
• The ProjectExplorer::Task may be confused with Utils::TaskTree framework and one may think that both classes may work together - that's wrong impression.

D) Make most of current GroupItem's subclasses final?

E) Add some tests for triggering the appropriate runtime assert (e.g. putting 2 instances of OnGroupSetup handler into one Group, placing 2 instances of the same copy of Storage into the tree, etc...).

F) Pimpl GroupItem, make it implicitly shared - for Qt adaptation puproses. Measure somehow the impact, though it should be probably neglected.

G) Refactor GroupItem c'tors

H) When stopping a tasks inside a Group, stop them in reverse order