Scale validation workers to the host, and let callers override it

[dionmcm]

Branch: perf/scale-validation-workers · Module: snomed-drools-engine

Problem

int threads = concepts.size() == 1 ? 1 : 10; - hardcoded.

On a 32-core CI node that leaves 22 cores idle; on a 2-core container it over-subscribes. With the scheduling barrier removed (perf/rule-executor-rolling-workers) rule execution is CPU bound and scales with cores, so the constant is the limit.

Change

• Default worker count is Runtime.getRuntime().availableProcessors().
• setValidationThreads(int) / getValidationThreads() for programmatic control.
• An execute(..., int validationThreads) overload for per-call control; the existing signature delegates to the configured default, so no caller breaks.
• snomed.drools.validation.threads system property for operators.
• Never more workers than concepts, so validating one concept still uses one.

Measured on 8 cores

Workers	Rule execution
4	86s
8 (default here)	59s
16	64s

Halving workers costs 46% and the optimum sits at about the core count, so availableProcessors() is a sound default. Findings were 10,949 at every setting.

These figures were taken with perf/rule-executor-rolling-workers also applied. On unmodified master the
worker count is also the size of the batch that doValidateComponents barriers on, so raising it widens the barrier as well as the pool and the benefit is capped. This change stands on its own - a fixed 10 is wrong on any host that is
not a 10-core machine - but it pays fully only once the barrier is gone.

Notes for review

Memory scales with this value: createKieSessionMap builds one StatelessKieSession per worker per rule set. On a many-core host running many rule sets, that is the thing to watch, which is why it is overridable downwards as well as upwards.

---

About this series

One of five independent performance changes to the Drools validation path, measured against a real 722,404-concept AU edition Snapshot. Each is a single commit on master, builds and passes the full suite alone, and leaves the findings byte-identical: 10,949 before and after, with matching report TSVs.

Together they take a full-Snapshot validation from 636s to 118s.

This PR and perf/rule-executor-rolling-workers touch adjacent lines; whichever merges second needs a one-line rebase. There is no logical dependency and the order does not matter.