This is tracking issue.
For performance, tast needs sharding feature.

At the moment, two approaches are come up with.
1) Implement a scheduler to run tests in parallel as a part of tast framework.
  - pros:
    - tast can have more precise control of the task management. So;
    - Maybe run more efficiently.
    - Could provide unified logs for all tests, which is probably more
      useful for the users.
  - cons:
    - tast will have more complexity to maintain scheduler.
    - Assigning multiple DUTs to one job could be somehow challenging
      because it could conflict with lab infra design.

2) Split tests in autotest framework.
  Tast is run on autotest job. We could set up multiple autotests jobs.
  "tast list" reports the list of tests, so pre-splitting the
  test could be done in autotest layer.
  - pros:
    - Compared to 1), easier to implement.
    - Aligned to the current lab design.
  - cons:
    - The whole log could be split into several jobs
      - Note: the log for one test could be stored in one job, so probably ok for
        most use cases.
    - Maybe less efficient than 1), because assigned tests could not
      be updated online.

Maybe 2) is a good starting point, because it has less feature, but simpler under the current situation.

Marking P3, because we'd like to prioritize precondition.