Bump org.hl7.fhir.core to 6.3.25

[dotasek]

This bumps the org.hl7.fhir.core dependency to 6.3.25

[github-actions]

Formatting check succeeded!

[dotasek]

There is a change to the org.hl7.fhir.core validator that is of note, and may require redesign of our own validation implementation.

Internally, HAPI has logic that switches unknown code system validation issues to a specified level:

https://github.com/hapifhir/hapi-fhir/blob/master/hapi-fhir-validation/src/main/java/org/hl7/fhir/common/hapi/validation/support/UnknownCodeSystemWarningValidationSupport.java

The InstanceValidator now has similar internal logic that switches between reporting warnings and errors:

hapifhir/org.hl7.fhir.core@7fc34e5

Since in many cases we throw warnings instead of errors, the processing of error messages and severity by the core validator logic is made even less straightforward. This is evidenced by the still correct, but less informative warnings created by some of our tests after this update: df77506

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 83.52%. Comparing base (406db33) to head (228f618).
Report is 54 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #6293      +/-   ##
============================================
- Coverage     83.54%   83.52%   -0.02%     
- Complexity    27432    27625     +193     
============================================
  Files          1707     1720      +13     
  Lines        106185   106944     +759     
  Branches      13397    13453      +56     
============================================
+ Hits          88710    89328     +618     
- Misses        11750    11834      +84     
- Partials       5725     5782      +57     

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

[dotasek]

@jamesagnew I made a disturbing discovery about this yesterday while trying to switch to using setUnknownSystemsCauseErrors

UnknownCodeSystemWarningValidationSupport is actually very interactive with InstanceValidator's setUnknownSystemsCauseErrors. The way our validation implementations currently work, one can't exist without the other, and 'setUnknownSystemsCauseErrorsmust always betrue`.

I'm working on splitting UnknownCodeSystemWarningValidationSupport into UnknownCodeSystemWarningValidationSupport and UnknownCodeSystemValidationSupport, the latter of which will support 'setUnknownSystemsCauseErrors` being true or false.

If there is a need for a core update before HAPI's code freeze however, I suggest removing the exposure of setUnknownSystemsCauseErrors for the time being, and sticking with the passing configuration we have today.

[dotasek]

After discussion with @markiantorno it was decided to hold off exposing setUnknownSystemsCauseErrors. In after the latest commit, this setting will always be true for the instance validator. This preserves the expected errors (in severity, if not the exact message), passes tests, and marging this wouldn't block additional core version bumps, in contrast with having to work on a resolution to the entangled implementation.

If this is acceptable, this PR should be merged, and I will open a linked ticket that can be worked on independently, to re-expose setUnknownSystemsCauseErrors and deprecate UnknownCodeSystemWarningValidationSupport.