Investigate Generate Task Usage

Currently, generate.tasks supports a feature where a task could generate a display task and add pre-existing tasks onto it. 

For example, `existing_task` could call generate.tasks to create `generated_display_task` and `generated_execution_task` and add itself to the newly generated display task. This is generally fine but a problem occurs if the existing task is stranded and has to restart. 

In a case where the existing_task restarts itself and has execution 1, the generated display and execution tasks will have an execution of 0 because it has not run before. One solution to this problem is to disallow users from adding pre-existing tasks to generated display tasks. Even with this limitation, users can still emulate this previous behavior by explicitly creating the display task in the yaml and placing this generated task within this display task. 

Another solution to this problem could be to start off the generated tasks' executions as the generator tasks' execution. In this case, if the exsting_task is stranded and has to restart, the generated tasks would also start off with an execution of 1. 

This use of generate.tasks is primarily seen in server and we want to investigate if disallowing existing tasks to go into generated display tasks would break their tests or if there is a reason that this is the way the tests are written.

Example display task

Attached two screenshots illustrating that in this case an execution task can have 1 more execution than its associated display task (and some confusing statuses that come with the situation).