Fixing concurrency issue in VersionSpecificWorkerContextWrapper (#6554)

[Boereck]

When validating if a code is valid against a ValueSet, a potentially cached (and therefore shared) result object was mutated. This mutation is now done on a copy of the result object.

Without this change, there might be a concurrent modification on a cached result of validateCodeInValueSet (item added to issue list). We got ConcurrentModificationExceptions when validating resources with the same problem in parallel.

Please let me know if there is an issue with this PR. Unfortunately, due to the concurrent nature of the problem, it seems impossible to test for the absence of the fixed error deterministically.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 83.59%. Comparing base (78537ba) to head (33b4be0).
Report is 8 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff            @@
##             master    #6648   +/-   ##
=========================================
  Coverage     83.58%   83.59%           
- Complexity    28650    28659    +9     
=========================================
  Files          1798     1799    +1     
  Lines        111363   111393   +30     
  Branches      13982    13983    +1     
=========================================
+ Hits          93080    93114   +34     
+ Misses        12280    12278    -2     
+ Partials       6003     6001    -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[Boereck]

I have added a test case to org.hl7.fhir.common.hapi.validation.validator.VersionSpecificWorkerContextWrapperTest that actually tests for the problem. Since this is a concurrency bug, it uses concurrent access to trigger the problem. This, unfortunately, makes the test case non-deterministic (the test case could theoretically pass, despite the bug being present), even though it works every time on my machine. I did split the change into two commits. The first commit contains the test case, and if this commit is checked out (without the second commit), the test case will fail. The second commit contains the fix, so the test case will pass.