Fix ParallelLoopExecution abandoning in-flight iterations and miscounting MinimumIterations

[Ankit Sharma (ankitsharma-99)]

Problem

Two defects in ParallelLoopExecution.ExecuteComponentLoopAsync:

1. In-flight iterations are abandoned when Duration elapses. On timeout the loop breaks out of
   Task.WhenAny without cancelling or awaiting the child. The child keeps running on the profile token and
   is only stopped as a side effect of profile shutdown when the loop happens to be the last action. Nothing
   awaits its cleanup, so:
   • its logs and upload requests are written after FileUploadMonitor's final drain and are not uploaded in
     the same run;
   • its processes can outlive VirtualClient;
   • if the loop is not the last action, the abandoned iteration runs concurrently with subsequent work.
2. currentIteration is incremented twice per pass (at the top of try and again in finally), so the
   guards evaluate 1, 3, 5, ... . MinimumIterations: 1 therefore guarantees no completed iteration, and
   MinimumIterations: N guarantees only floor(N/2).

Example: with children that run for 30 minutes and Duration: 00:40:00, one iteration completes, a second
starts with 10 minutes remaining and is abandoned about 10 minutes in. With Duration equal to the child
duration and MinimumIterations: 1, the only iteration is abandoned at the deadline.

Fix

Restores the documented contract (website/docs/guides/0011-profiles.md): run until Duration, and let
MinimumIterations guarantee complete iterations.

• A single deadline CancellationTokenSource (CancelAfter(Duration)) replaces the timeoutTask field and is
  shared by all parallel loops.
• Iterations required to satisfy MinimumIterations run with a token linked only to the caller's token, so
  they complete even if Duration elapses.
• Later iterations run with a token linked to both the caller's token and the deadline. When the deadline
  elapses the iteration is cancelled and awaited; no child task is left running when the component returns.
• The counter tracks completed, non-cancelled iterations only, incremented once.
• MinimumIterations default remains 1, docs corrected to match.
• Per-iteration telemetry context is cloned instead of mutating the context shared by the parallel loops.
• XML docs for Duration and MinimumIterations corrected.

Behavior

Children that run for 30 minutes:

Duration	MinimumIterations	Before	After
40m	1	1 complete + 1 abandoned	1 complete + 1 cancelled and awaited at 40m
30m	1	only iteration abandoned at 30m	1 complete
40m	2	1 complete + 1 abandoned	2 complete
30m	0	abandoned at 30m	cancelled and awaited at 30m
none	any	loops until cancelled	unchanged

Unchanged: children still run in parallel, unsupported components are skipped, caller cancellation stops all
loops, and child exceptions propagate as before.

Testing

• New tests:
  • ParallelLoopExecution_CancelsAndAwaitsTheInFlightIterationWhenTheDurationElapses
  • ParallelLoopExecution_CompletesTheMinimumIterationEvenWhenItExceedsTheDuration
  • ParallelLoopExecution_CancelsAndAwaitsAnIterationBeyondTheMinimumWhenTheDurationElapses
  • ParallelLoopExecution_LoopsUntilCancelledWhenNoDurationIsDefined
• Existing MinimumIterations tests now assert exact completed-iteration counts instead of start counts.
• VirtualClient.Core.UnitTests: 968 passed, 0 failed, 1 skipped (pre-existing flaky test).

Out of scope

A cancelled iteration still emits a Succeeded scenario metric, because VirtualClientComponent.ExecuteAsync
treats OperationCanceledException as success. That behavior is in the base component, not this loop.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.