[Feature]: Provide groups to reporter preprocess hook so custom sharding can handle serial mode

🚀 Feature Request

Following up from https://github.com/microsoft/playwright/issues/17969#issuecomment-5167739692

New Reporter hooks allow for custom handling of sharding tests using timing data. The provided example in the linked comment doesn't handle serial mode correctly: tests in a serial block can be split across multiple shards instead of being run serially.

Playwright's built in sharding already accounts for serial mode by calculating test groups: createTestGroups() in packages/playwright/src/runner/testGroups.ts, returning TestGroup[] where each group is "tests that must be run in order".

Custom reporters could be made to handle serial mode if these groups were made part of the public API.

Example

Now: To avoid splitting a serial group, preprocess has to re-derive
Playwright's own grouping from the _parallelMode private field:

// the suite that forces this test to run in sequence with its siblings
let group: Suite | undefined;
for (let s = test.parent; s; s = s.parent) {
  const mode = (s as any)._parallelMode;   // private
  if (mode === 'serial' || mode === 'default')
    group = s;
}

Wanted. The grouping handed to the reporter, so nothing is re-derived:

preprocess({ testRun }) {
  for (const group of testRun.groups()) {
    // assign each group to a shard, never split one
  }
}

Motivation

See https://github.com/microsoft/playwright/issues/17969 for context on why timing-based sharding is a necessity for many. Similarly, although serial mode is discouraged, it is a practical necessity for cases where setup or test steps are expensive to run and can't be done arbitrarily many times.

In real terms, I personally have several tests that have a 2 minute bottleneck to set up a shared resource, but once that step is done I can execute several scenarios quite quickly. If I made these all purely parallel and independent from each other, it explodes the runtime of my suite. This slow step is exactly the same reason why I have bunching problems with Playwright's default sharding algorithm. If all tests are fast and can be run in any order, Playwright's default sharding is fine. When a subset of tests is slow, the default sharding and fully parallel test design both break down.

Given that Playwright has decided to support custom sharding algorithms through the Reporter hooks, and Playwright already uses logic for grouping together tests that must run together in its own sharding algorithm, exposing this information seems like a simple way to improve the options a user has without creating significant new maintenance burdens. As a user, I feel much more confident about implementing my own sharding decisions if I can base it on the concepts Playwright already uses.