Improve interpretation of term service OperationOutcome results

[ewoutkramer]

When terminology services are called to validate a code, the "happy path" will return either true (code valid) or false (code invalid), but additionally, a terminology service can also return an OperationOutcome when the processing failed (no positive statement about the code being valid or invalid).

Currently, we will return a FhirOperationException in this case, which carries the http status code. Based on this, the validator should react differently - most importantly is handling the 404, which means the term server cannot resolve a required codesystem or valueset. Although documented insufficiently in the current FHIR spec, a reasonable list would be:

200 - ok - use result of operation
401 - unauthorized
403 - forbidden
404 - not found (codesystem/valueset unresolvable)
422 - we sent an incorrect request (parameters)
501 - not implemented

404 should specifically be handled by our multi-terminology-service implementations who should the move on to the next terminology service in the list. This might also be true for 501, 401 and 403. With 422, a retry is useless, and this should be handled as an exception (a software mistake on our side). 401/403 should clearly be communicated to the end user.

Thanks to CSIRO for supplying me the list of http result codes returned by Ontoserver with me!

[ewoutkramer]

@mmsmits - are we doing this in our multitermservice stuff?

[mmsmits]

Currently we catch all FhirOperationExceptions and move on to the next.
We could make a distinction, but maybe another terminology server is more flexible and allows incorrect requests (422).

[mmsmits]

This should wait until we have a definitive list on how to handle response codes from Grahame

[mmsmits]

See also: #2685