Optimize coverage executions

[anonrig]

• Replaces hard-coded 4 threads to 16 for coverage file parsing parallelism.
• Realized that forkjoinpool resource was not properly cleaned up.
• Parsed different file types in parallel rather than sequential.
• Optimized directory walking.

[gemini-code-assist]

Code Review

This pull request introduces significant performance optimizations by leveraging parallel processing for coverage file parsing and directory walking. The changes include dynamically adjusting the parallelism level based on available processors, using CompletableFuture to parse different file types concurrently, and ensuring proper cleanup of ForkJoinPool resources. Additionally, the filtering logic for coverage files has been extracted into a dedicated method, improving code readability and maintainability. Overall, these are valuable improvements for the tool's efficiency.

[c-mita]

Have you got any tests that can quantify the impact of these changes?

Replaces hard-coded 4 threads to 16 for coverage file parsing parallelism.

When making changes relating to the memory usage of the coverage merger, I noticed that increasing parallelism didn't really appear to change much, and in the context of very large reports, could actually make things worse.

[c-mita]

How many parsed coverage reports can be "in-flight" at a time with this approach?

Previously it was just double the number of threads; each thread had the "accumulated" report and the currently parsed one. I'm not sure that's the case here.