Fix flaky P2 test failures caused by parallel fork lock contention

[mirkoalicastro]

This PR aims to fix Fix flaky P2 test failures.

Context

lib-extra:test runs with maxParallelForks = Runtime.runtime.availableProcessors().intdiv(2).

Each Gradle test fork is a separate JVM. When multiple forks simultaneously call model.query(), they race for a process-level file lock causing one of the 2 forks to get an IllegalStateException (P2 operation already in progress).

TestP2Provisioner already has sync mechanism, but that only works within one JVM and not across multiple forks.

Fix

Override maxParallelForks = 1 in lib-extra/build.gradle. One fork is enough because the TestP2Provisioner synch handles thread safety within one JVM, and its disk cache ensures P2 deps are provisioned once and reused across all test classes.

I don't expect meaningful slowdown since with 2 forks the parallel gain was already lost to lock failures and testRetry reschedules. Also, I expect this to make the pipeline more stable.

[jochenberger]

Is there any chance we can fix the underlying issue? We're getting similar issues in CI across different builds, e.g. when they run simultaneously.

[nedtwigg]

Fixing the underlying issue means fixing something in Solstice. We have so many problems integrating with the eclipse ecosystem. My advice to end users is to migrate to a different platform, but I'm happy to keep merging PRs from interested parties.

[jochenberger]

What exactly do you mean by "different platform"? For Groovy code formatting, the options are pretty limited unfortunately.

[nedtwigg]

lol, fair point. I guess I would take one of the following options:

1. I accept all this P2 weirdness roughly as-is
2. I'm just gonna format Groovy with trimTrailingWhitespace and indentWithTabs
3. I'm gonna use an LLM to turn my Groovy into Kotlin and use kotlin formatters

My personal vote for my work on Spotless is that I'm just gonna accept the P2 weirdness. But if that was unacceptable, I would do 2 or 3.

If you want to fix Solstice and the whole p2 deployment / GrEclipse tooling ecosystem, I think doing 1, 2, or 3 would almost certainly be a more efficient use of time. But I'll merge any PR that meets a reasonable quality bar!

[jochenberger]

I guess I'll also go with option 1 then. I just wanted to make sure that I'm not missing an obvious alternative. I just noticed that locking issues in the Groovy formatter habe become more common in the last couple months or so. But maybe we're just running more builds. 🤷🏼‍♂️
I'd love to take a stab at fixing an issue in solstice, but I have tried to dig into its inner mechanisms but failed so far. OSGi and friends are still sorcery to me and my experience over the last 2 decades is that this is probably not going to change. Ever.