Profile handling interceptor

[JohnTimm]

Create a FHIR Persistence Interceptor than the implements the following profile handling:

1. If profile is not asserted in meta.profile, FAIL.
   NOTE: this may need to be configuration driven.
2. If profile is asserted in meta.profile but does not match to a profile we support, FAIL.
3. If profile is asserted in meta.profile and matches to a profile we support, validate data. If valid, PASS. If invalid, FAIL

[michaelwschroeder]

After discussion with team, design will be as follows:

1. This will not be implemented as an interceptor, but will be in the FHIRRestHelper validation code path
   • will be limited to HTTP API path, so will not include $validate operation or other validation paths outside the API
   • will be configurable through fhir-server-config.json file, so will be tenant-specific and dynamic
2. Via the config, tenant will be able to list a set of profiles, one or more of which a resource must assert. The config can be resource type-specific (fhirServer/resources/<resourceType>/profiles/atLeastOne) or apply to all resource types (fhirServer/resources/Resource/profiles/atLeastOne). The all-resource-types config will apply for resources which do not have a resource type-specific config:

{
    "__comment": "FHIR Server configuration",
    "fhirServer": {
        "resources": {
            "open": true,
            "Patient": {
                "profiles": {
                    "atLeastOne": [
                        "profile1",
                        "profile2",
                        "profile3"
                    ]
                }
            },
            "Resource": {
                "profiles": {
                    "atLeastOne": [
                        "profile4"
                    ]
                }
            }
        },
        ...
    }
}

3. If a non-empty atLeastOne list is specified, a resource must assert one or more of the profiles in the list, or the request will FAIL
4. If an empty list is specified, or the atLeastOne property is not specified at all, 'normal' validation will be performed (if not supported, a warning will be issued, if data validation fails an error will be issued)
5. If an asserted profile does not match a profile the FHIR Server supports, the request will FAIL
6. If a profile is asserted and it's supported, the resource will be validated against the profile. If valid PASS, if invalid FAIL

As long as a resource meets the above requirements it can assert any number of other profiles. However, those profiles must pass steps 5 and 6 just like required profiles must.

[d0roppe]

I have verified steps 3, 4, 5, and 6 with different fhir-server-config.json files. and the code is working as described.

[michaelwschroeder]

Updated functionality to handle versioned profiles is addressed in issue #1725