Introduce the concept of parent-child Swarming task

[GoogleCodeExporter]

Repro:
1. swarming.py trigger ...
2. The task itself runs swarming.py trigger ... to generate one or multiple 
subtasks (e.g. tests)

Expected:
There's an association in the DB and UI about the parentship of the tasks.

Actual:
They are completely distinct.

AI:
- Set in task_runner.py a new environment variable SWARMING_TASK_ID set to the 
task id.
- Change swarming.py trigger to look for SWARMING_TASK_ID and pass it at the 
create task API.
- Change the server to accept new "parent_task_id" property and save it in 
TaskRequest.parent_task_id.
- Surface this data in the UI.

This is relatively simple to implement. Eventually this knowledge could be 
leveraged. The main risk is there is no protection against tampering.

Original issue reported on code.google.com by maruel@chromium.org on 19 Jan 2015 at 10:02

[GoogleCodeExporter]

There's some overlap with LUCI scheduler here. What exactly will we gain by 
storing this association on Swarming level?

Original comment by vadimsh@chromium.org on 20 Jan 2015 at 8:38

[GoogleCodeExporter]

Knowledge is power. More seriously, right now it's valuable information. I do 
not want to make reentrant tasks a panacea but it's helpful in the case of 
multi-device cooperation.

Original comment by maruel@chromium.org on 20 Jan 2015 at 9:09

[GoogleCodeExporter]

Original comment by maruel@chromium.org on 25 Jan 2015 at 11:33

• Changed state: Fixed