Omit retired resource types in whole-system interactions

[lmsurpre]

Is your feature request related to a problem? Please describe.
FHIR R4B removes a number of resource types.
Per #2065 our plan is to omit those from the REST API, but leave them in the DB (so an R4 server could still come along to use those).

Where that gets a bit complicated is in the whole-system interactions (search, history, reindex, etc).

Describe the solution you'd like
Omit the resource types that have been removed in R4B from the results of both whole-system search and whole-system history.

Describe alternatives you've considered
Continue to return these resource types from whole-system search and/or history.

Acceptance Criteria

1. GIVEN an R4 database with some retired resource type content (e.g. EffectEvidenceSynthesis)
   AND the deployment is updated to R4B
   WHEN a client sends a whole-system search query that would return that resource in R4 (e.g. GET [base]/)
   THEN the search-response bundle does NOT contain the resource

2. GIVEN an R4 database with some retired resource type content (e.g. EffectEvidenceSynthesis)
   AND the deployment is updated to R4B
   WHEN a client sends a whole-system history request that would return that resource in R4 (e.g. GET [base]/_history)
   THEN the history-response bundle does NOT contain the resource

3. GIVEN an R4 database with some retired resource type content (e.g. EffectEvidenceSynthesis)
   AND the deployment is updated to R4B
   WHEN a client sends a $reindex request that would process that resource in R4 (e.g. POST [base]/$reindex)
   THEN the reindex request succeeds and the retired resource instances are skipped / not reindexed

Additional context
Add any other context or screenshots about the feature request here.

[lmsurpre]

I'm thinking to also change the server behavior in cases where the server prohibits certain interactions on certain resource types (e.g. when /fhirServer/resources/open is set to false).

For example

• if we support [read, vread, create, update] but not [search] for a particular resource type, I will omit that resource type from the whole-system history results.
• if we support [read, search] but not [history] for a particular resource type, I will omit that resource type from the whole-system history results.

Those edits might require deeper changes and also more testing, so I'm bumping the estimate to 5.

[lmsurpre]

one option I’m considering is to introduce a new config property to control this behavior. something like fhirServer/core/useImplicitTypeScopingForWholeSystemInteractions.

it would default to true and work as described in the previous comment
but for users that know they only have resource types that they actually want to expose, they could set this to false and get the current behavior which is to try reading ALL the resources (no implicit resource type filter)