Speed up SimpleCov.collate with optional multi-process merge

[danielwestendorf]

This is an AI-Assisted PR

Collating the resultsets from a large CI matrix is slow in a way that scales badly. The collating process reads, parses and folds every shard in sequence, and nearly all the wall clock goes into that fold. This PR let's this process run on more than one core, speeding up overall collation.

Tested on real CI 1 process vs multi-processes (CI node cpu count = 4) for 160 real resultsets on a 231k line rails app saw collate reduce from 49sec to ~30sec.

┌────────────────────────┬─────────────┬──────┐
│                        │ merge time  │      │
├────────────────────────┼─────────────┼──────┤
│ single process         │ 49s         │      │
├────────────────────────┼─────────────┼──────┤
│ processes: 4           │ 30s         │ −61% │
├────────────────────────┼─────────────┼──────┤
│ processes: 6           │ 28s         │ −77% │
└────────────────────────┴─────────────┴──────┘

The API change

SimpleCov.collate takes a new processes: argument:

SimpleCov.collate Dir["simplecov-resultset-*/.resultset.json"], processes: 6

It defaults to 1, which never forks, so existing calls are completely unaffected — same code path as before. Everything else about the signature is unchanged.

Early attempts used Etc.nprocessors to automatically tune process count, however, this often reports the number of processes of the host machine, not the vm/container of which it runs, so I opted for manual tuning. Setting ENV var SIMPLECOV_CONCURRENCY will also work.

Failure handling

Every failure path returns nil rather than a partial merge, and the caller redoes the fold in-process. Reporting coverage for a subset of the resultsets would silently understate it, which is a worse outcome than being slow. That covers:

• a runtime that cannot fork — JRuby, TruffleRuby, Windows. Detected by the NotImplementedError the call raises, not by respond_to?, since those runtimes define Process.fork and only raise when it's invoked
• a worker that died
• a payload that came back truncated

Workers ship their folded pair back over a pipe, deserialized on a thread per worker so every pipe is drained while the workers are still writing — otherwise a payload larger than the pipe buffer blocks its worker mid-write and the parent blocks reaping a worker that can never finish. Children end with exit! so they never fall through to the collating process's at_exit handlers. Each worker folds its slice one file at a time, as the serial path does, so memory scales with the worker count rather than the resultset count.