Allow clients to request search results without resource contents

[lmsurpre]

Is your feature request related to a problem? Please describe.
We already support variants for controlling what comes back from a search:

• _summary=count will return just the total (with no entries)
• _summary=true will return SUBSETTED resources with only summary elements
• _elements=id will return SUBSETTED resources with only required elements (and modifier elements)

However, there is no way to get a list of resources which match the query without getting the resources themselves.

Describe the solution you'd like
Similar to #2026 I was thinking it might be neat to support this behavior through the use of the HTTP Prefer header.

Describe alternatives you've considered
none

Acceptance Criteria

GIVEN a search request
WHEN no Prefer header is passed
THEN the response returns the resource contents in the response entries (spec-compliant)

GIVEN a search request
WHEN Prefer: return=minimal is passed
THEN the response returns no resource bodies in the response entries

GIVEN a search request
WHEN Prefer: return=representation is passed
THEN the response returns the resource contents in the response entries

Additional context
Sister issue for #2026 ...should probably be done together

[lmsurpre]

easiest impl: just don't attach the resources to the response bundle

better impl: avoid the join with the resources table in the jdbc persistence layer

open question: should we return the lastUpdated time somewhere in the search response (in addition to resource id and version that are in fullUrl)?

[lmsurpre]

Implementing this together with or after #2432 could give a nice way to choose the easiest-to-implement-option (no persistence-layer changes outside of 2432) while still having some server-side performance boost.

[lmsurpre]

open question: should we return the lastUpdated time somewhere in the search response (in addition to resource id and version that are in fullUrl)?

/_history is prohibited in the fullUrl for some reason, so the version would need to be communicated elsewhere...probably in the Bundle.entry.response.location as suggested in #2026 for the history api

[kmbarton423]

Ran a variety of searches including patient compartment with all supported search result parms. Ran with and without the Prefer return= header using settings of minimal, representation, and OperationOutcome. Search results were as expected given the Prefer setting.