support `resources/<resourceType>/profiles` properties from $validation when mode is set

[lmsurpre]

Is your feature request related to a problem? Please describe.
While validating #2873 and #2834 I realized that we only exercise these rules during ingestion and not validation.

The $validate endpoint serves multiple use cases:

1. exposes general profile validation (the default)
2. allows clients to ask if a given resource is valid for this server

The input parameter that controls this switch is called mode but I think we mostly ignore that today.

Describe the solution you'd like
When $validate is called with a mode of create or update, we should make use of the applicable fhir-server-config fhirServer/resources/<resourceType>/profiles config properties so that the response will reflect the expected result of an attempted create/update request with this same content.

Describe alternatives you've considered

Acceptance Criteria

1. GIVEN [a precondition]
   AND [another precondition]
   WHEN [test step]
   AND [test step]
   THEN [verification step]
   AND [verification step]

Additional context

[michaelwschroeder]

With the changes implemented via this issue, the $validate operation logic is as follows:

• If a profile is specified via the profile parameter, the $validate operation will validate a resource against the base specification and the specified profile only. It will not validate against any profiles asserted in the Resource.meta.profile element.
• If the profile parameter is not specified, but the mode parameter is specified, and the mode parameter value is either create or update, the $validate operation will validate a resource against the base specification and any profiles asserted in its Resource.meta.profile element, and will do so based on profile configuration properties specified in the fhirServer/resources/<resourceType>/profiles section of the fhir-server-config.json file
• If neither of the above conditions is true, the $validate operation will validate a resource against the base specification and any profiles asserted in its Resource.meta.profile element. Profile configuration properties will be ignored.

[lmsurpre]

I verified that I am now able to invoke the $validate operation with a mode parameter such as with the following:

{
	"resourceType": "Parameters",
	"parameter": [
		{
			"name": "mode",
			"valueCode": "create"
		},
		{
			"name": "resource",
			"resource": {
				"resourceType": "Patient",
				"id": "{{patient}}",
				"meta": {
					"profile": [
						"profile1"
					]
				}
			}
		}
	]
}

As defined in the spec, the response code is 200 OK whether there are validation errors or not.

The profile validation logic does appear to be in line with the configuration.

config	Resource.meta.profile	mode	outcome-severity	outcome-text
"allowUnknown": false	profile1	create	error	Profile 'profile1' is not supported
"allowUnknown": true	profile1	create	warning	Profile 'profile1' is not supported
"allowUnknown": false	profile1	update	error	Profile 'profile1' is not supported
"allowUnknown": true	profile1	update	warning	Profile 'profile1' is not supported
"allowUnknown": false, "defaultVersions": {"profile1": "1.0.0"}	profile1	create	error	Profile 'profile1|1.0.0' is not supported
"defaultVersions": {"profile1": "1.0.0"}, "notAllowed": ["profile1|1.0.0"]	profile1	create	error	A profile was specified which is not allowed
"defaultVersions": {"profile1": "1.0.0"}, "notAllowed": ["profile1|1.0.0"]	profile1	profile	warning	Profile 'profile1' is not supported

Interestingly, it also allows any other value for mode...even a bogus value (despite the spec saying this field has a required binding to valueset-resource-validation-mode:

config	Resource.meta.profile	mode	outcome-severity	outcome-text
"allowUnknown": false	profile1	delete	warning	Profile 'profile1' is not supported
"allowUnknown": false	profile1	profile	warning	Profile 'profile1' is not supported
"allowUnknown": false	profile1	bogus	warning	Profile 'profile1' is not supported

I think we should clean that up, but its definitely lower priority since the operation does work as documented in the user guide.

[lmsurpre]

I opened #2964 for the remaning work I see on getting $validate spec-compliant.