Duplicate bundles for repeats before minimizing simulator count

[RainNapper]

Partial resolution of #424

Swap the repeat logic to run before we decide to minimize the simulators to match the bundle size.

If you were running with 10 sims, 1 test, 2 repeats, then the existing logic would cut your sims from 10 to 1, then duplicate bundles from 1 to 2. This left the repeats running in series.

In this change, this would duplicate bundles from 1 to 2, then cut sims from 10 to 2.

Some output of this run:

{84002} 20200407.130243 [  INFO  ] (BLUEPILL) Using xctestrun configuration
{84002} 20200407.130243 [  INFO  ] (BLUEPILL) This is Bluepill v5.2.0-1-g01c5147
{84002} 20200407.130243 [  INFO  ] (BLUEPILL) Packing test bundles based on test counts.
{84002} 20200407.130243 [  INFO  ] (BLUEPILL) Duplicating test bundles 1 time(s) for test repeats
{84002} 20200407.130243 [ WARNING] (BLUEPILL) Lowering number of parallel simulators from 10 to 2 because there aren't enough test bundles.
{84002} 20200407.130243 [  INFO  ] (BLUEPILL) Running with 2 parallel simulators.
{84002} 20200407.130243 [  INFO  ] (BLUEPILL) Packed tests into 2 bundles

Notice the timings indicate they are in fact running in parallel.

{84023} 20200407.130244 [  INFO  ] (BP-1) Running Tests. Attempt Number 1.
{84054} 20200407.130245 [  INFO  ] (BP-2) Running Tests. Attempt Number 1.
{84023} 20200407.130402 [ PASSED ] (BP-1)  50.217322s TestClass/TestName
{84054} 20200407.130406 [ PASSED ] (BP-2)  53.405522s TestClass/TestName

Also verified by running non-headless, and it showed multiple simulators running the same test in parallel.

I was not sure of a great way to test this since I did not see clear points of abstraction, or how to check the number of simulators running in an integration test. Please advise if you feel I should add tests.

[jerrymarino]

With the goal of handling retris inside of bluepill, I think we can move this logic into the main runloop. e.g. When a test fails, simply add repeatTestsCount bundles. Then disable retries in the subprocess

[RainNapper]

This change is not explicitly targeting failure retries. While there might be an option to solve both issues in the same way, this simply enables running a test multiple times, regardless of if the first run passes or fails.

[ravimandala]

LGTM. Can you add a test or two?

[ravimandala]

@RainNapper I took another hard look at the changes and I feel the replication should be done early on.

For example, the Packing step would sort the bundles by test count (or test time estimates, if provided). In the case of multiple test bundles being replicated, packing before bundle replication is would not give the sorted bundles as one would expect.

If you fix this, then you can test this the same way we test the packing step.