WIP: Proof of Concept of HL7 Validator Wrapper integration

[dehall]

Summary

(Note: this is based off of the validator error handling change which was just reverted so the diff may look a little odd)

This PR demonstrates a proof of concept of using the HL7 validator wrapper instead of our wrapper for resource validation. There are a few other things we will want to do in practice but those should be straightforward to implement once we know whether this is the direction we want to go.

The key changes are as follows:

1. The HL7 validator wrapper /validate endpoint request and response use the ValidationRequest and ValidationResponse classes from the org.hl7.fhir.validation library, so we will need to map our input and output appropriately. This is pretty straightforward, see new functions wrap_resource_for_hl7_wrapper and operation_outcome_from_hl7_wrapped_response below
2. The HL7 validator uses sessions to ensure different IGs and combinations of settings don't stomp on each other. Spinning up a new session is slow. To ensure good performance, we need to keep track of sessions so that a test suite will re-use the same session ID. There are some other options we could pursue here, including a global session cache, or various changes to the HL7 session management code, but the bare minimum is to keep track of the session ID the previous call returned in an instance variable and re-use that for subsequent calls.
3. Test suites can specify the IGs they need via a new DSL method igs, which takes a list of IG identifiers . For example for the US core 3 test suite it will look like this:

      validator do
        url ENV.fetch('V311_VALIDATOR_URL', 'http://validator_service:4567')

        igs ['hl7.fhir.us.core#3.1.1']

        ...
      end

If the IG isn't published yet, then you can pass in a filename here and it will work just fine. (See https://confluence.hl7.org/display/FHIR/Using+the+FHIR+Validator#UsingtheFHIRValidator-LoadinganimplementationGuide for what's accepted) Filenames appear to be relative to the base directory of the HL7 validator wrapper but we will probably need to test different deployment scenarios to confirm.

There are other things we will want to make configurable, such as the terminology server and whether code display issues should be warnings - those can either be made separate DSL functions or we could just make the whole cliContext of the request configurable

---

Other things we may want to do:

4. Trigger a session at startup so that the first real validation request is fast. This can potentially just be a call to validate with an empty resource from the constructor but I'm not sure how to make this performant
5. Make changes to the validator's internal session logic:
   a. allow the validator to re-use a session for requests with the same cliContext . This would be much easier than implementing a session cache on our side. I'm not sure if that team will want to make this change though. A basic implementation of that is here: https://github.com/dehall/org.hl7.fhir.core/tree/session_by_clicontext . Diff: hapifhir/org.hl7.fhir.core@master...dehall:org.hl7.fhir.core:session_by_clicontext
   To run this locally you'll need to install the fork to maven local with the new version, and update the wrapper to point to that new version. An easier method is to use the Dockerfile located in this fork of the HL7 wrapper:
   https://github.com/dehall/org.hl7.fhir.validator-wrapper

docker build --tag hl7_wrapper_fork -f Dockerfile.fork .
docker run -it -p 8081:8081 hl7_wrapper_fork

b. allow modifying the validator session cache expire time. There is a constructor for the session cache that takes in an amount of time but it's not invoked by the validation service. Not a huge change but I'm not sure what the best way to make it is

Testing Guidance