Read the RF2 files concurrently, and make the repository safe for it

[dionmcm]

Branch: perf/parallel-rf2-loading · Module: snomed-drools-rf2-validator

Problem

loadComponentsFromRF2 passed multiThreaded=false (hardcoded), so RF2 files were read one after another even though ReleaseImporter.loadAll already has the structure to overlap them: the concept file inline first, then core component files, then reference set files, with a barrier between phases.

The flag was correctly false, because SnomedDroolsComponentRepository was not safe for concurrent writes. This change makes the repository thread safe with synchronisation and allows parallel loading increasing throughput.

Change

Guard the repository, then enable it:

• addDescription, addRelationship, addAnnotation and addOntologyAxiom lock the concept being appended to. Locking the concept stripes by concept, so it costs no memory and contends only when two rows touch the same concept at the same instant.
• addRelationship touches the source and the destination concept. Those two locks are taken separately, never nested - a relationship pair pointing at each other would otherwise give two threads the same two locks in opposite order, which deadlocks.
• The two release-wide sets, annotations and ontologyAxioms, are guarded like the existing descriptionMap.
• snomed.drools.parallelLoading=false restores the old behaviour - may be unnecessary but was preserved in case it was desired in some use cases

Descriptions resolve their concept, and language reference set members resolve their description, because the phase they depend on has completed and Future.get() ensures it happens before. Within a phase, the files that write the
same collections are the relationship/concrete-relationship pair and the description/text-definition pair, which is what the new locking covers.

Tests

SnomedDroolsComponentRepositoryConcurrencyTest drives 8 threads x 500 rows at a single concept and asserts nothing is lost, plus a reciprocal-relationship case that times out rather than passing if the lock order regresses.

With the locking reverted the tests fail with 3,964 and 3,975 of 4,000 entries arriving. A lost entry is a missing finding, not a crash, which is why this is tested.

Measurement

Load phase 94s -> 68s. Total 165s -> 118s across the three runs quoted above.
Findings of the assertions unchanged.

---

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/skip-effective-filter-single-snapshot touch adjacent lines; whichever merges second needs a one-line rebase. There is no logical dependency and the order does not matter.