Scope whole-system interactions to the intersection of R4 and R4B by default

[lmsurpre]

Is your feature request related to a problem? Please describe.
Building on the support added in #3137 ...

For example, for whole-system history:

• IBM FHIR Server 5.0 is deployed and instances of the new resource types are added to it
• An existing R4 client invokes whole-system history and, when they get to the page with the new resource type, they are unable to parse the response.

Similar scenarios exist for whole-system search and $export (and maybe $everything as well?)

Describe the solution you'd like
Introduce a fhir-server-config property that controls the server behavior when no fhirVersion is specified by the client. The default value for this property should result in the server only returning 4.0.1 resource types (but still not ones removed in 4.3.0).

Regardless of the setting, if the client passes an Accept header with a FHIR mime type that includes fhirVersion=4.3, and the new resource types are not filtered out in the fhir-server-config resources section, then include the new resource types introduced in R4B.

This is consistent with the CapabilityStatement behavior implemented for #3192 except that we should update that to support changing the default if the user wants something other than 4.0.1 to be the default behavior.

Describe alternatives you've considered
Force the IBM FHIR Server operator to explicitly list the set of supported resource types in their fhir-server-config and use exactly that set when the client doesn't pass any fhirVersion in their Accept header.
If they only want to server 4.0 resource types, then only list 4.0 resource types and set open=false.

If the client explicitly asks for fhirVersion=4.0 we could still omit all the resource types introduced in R4B.

If we went with this alternative, we'd need to update the CapabilityStatement behavior to match because, currently, that defaults to omitting the new R4B resource types (unless fhirVersion=4.3 is passed)

Acceptance Criteria

1. GIVEN a 5.0 IBM FHIR Server with resource type instances of types added in R4B (e.g. Ingredient)
   WHEN a whole-system history query is sent with no explicit _type parameter
   AND the client sets the Accept header to application/fhir+[xml/json];fhirVersion=4.3
   THEN the history response contains the R4B resource types

2. GIVEN a 5.0 IBM FHIR Server with resource type instances of types added in R4B (e.g. Ingredient)
   WHEN a whole-system search query is sent with no explicit _type parameter
   AND the client sets the Accept header to application/fhir+[xml/json];fhirVersion=4.3
   THEN the search response contains the R4B resource types

3. GIVEN a 5.0 IBM FHIR Server with resource type instances of types added in R4B (e.g. Ingredient)
   WHEN a system-level $export interaction with no explicit _type parameter
   AND the client sets the Accept header to application/fhir+[xml/json];fhirVersion=4.3
   THEN the $bulkdata-status response contains a download url for the R4B resource types

4. GIVEN a 5.0 IBM FHIR Server with resource type instances of types added in R4B (e.g. Ingredient)
   WHEN a whole-system history query is sent with no explicit _type parameter
   AND the client does NOT set the Accept header / sets it to application/fhir+[xml/json]
   THEN the history response does NOT contains the R4B resource types

5. GIVEN a 5.0 IBM FHIR Server with resource type instances of types added in R4B (e.g. Ingredient)
   WHEN a whole-system search query is sent with no explicit _type parameter
   AND the client does NOT set the Accept header / sets it to application/fhir+[xml/json]
   THEN the search response does NOT contains the R4B resource types

6. GIVEN a 5.0 IBM FHIR Server with resource type instances of types added in R4B (e.g. Ingredient)
   WHEN a system-level $export interaction with no explicit _type parameter
   AND the client does NOT set the Accept header / sets it to application/fhir+[xml/json]
   THEN the $bulkdata-status response does NOT contains a download url for the R4B resource types

Additional context
Similar to #3192 but for system interactions and not just the CapabilityStatement

[lmsurpre]

Introduce a fhir-server-config property that controls the server behavior when no fhirVersion is specified by the client. The default value for this property should result in the server only returning 4.0.1 resource types (but still not ones removed in 4.3.0).

This could easily be implemented in the same spot we set the default Accept header to application/fhir+json when none is passed (FHIRHttpServletRequestWrapper?)

[d0roppe]

Acceptance criteria 6 fails it exports the same resources as Acceptance critera 3.

[punktilious]

AC1: history with fhirVersion=4.3:

sh history_1.sh | grep resourceType | jq . | grep resourceType
  "resourceType": "Bundle",
        "resourceType": "Ingredient",
        "resourceType": "ClinicalUseDefinition",

AC2: search with fhirVersion=4.3:

sh search_2.sh | grep resourceType | jq . | grep resourceType
  "resourceType": "Bundle",
        "resourceType": "Ingredient",
        "resourceType": "ClinicalUseDefinition",

AC3: export with fhirVersion=4.3
We see R4B type Ingredient included in the export partition list:

[31/08/2022, 09:15:32:037 UTC] 00000032 forhealth.fhir.bulkdata.jbatch.export.fast.ExportJobListener I bulkexportfastjob[8]                       Ingredient          1

AC4: history without fhirVersion

sh history_4.sh | grep resourceType | jq . | grep resourceType
 "resourceType": "Bundle",
        "resourceType": "QuestionnaireResponse",
        "resourceType": "QuestionnaireResponse",

AC5: search without fhirVersion:

sh search_5.sh | grep resourceType | jq . | grep resourceType
  "resourceType": "Bundle",
        "resourceType": "QuestionnaireResponse",
        "resourceType": "QuestionnaireResponse",

AC6: export without specifying fhirVersion:
The exported resources shown are:

PractitionerRole          
Practitioner          
Goal          
DocumentReference  
Medication          
Organization          
CareTeam          
Encounter          
Provenance          
ImagingStudy          
AllergyIntolerance          
ExplanationOfBenefit          
CarePlan          
Procedure          
ValueSet          
Immunization          
Device          
MedicationRequest          
Observation          
MedicationAdministration          
Basic          
DiagnosticReport   
Condition          
Patient          
NutritionOrder          
QuestionnaireResponse          
Claim          
SupplyDelivery          
Location          

No mention of R4B resources.

Summary: in all the above cases the correct set of resources are seen.