$everything operation should support listing of patients based on context when called with Patient/$everything

[prb112]

Is your feature request related to a problem? Please describe.
Per the specification, If there is no nominated patient (GET /Patient/$everything) and the context is not associated with a single patient record, the actual list of patients is all patients that the user associated with the request has access to. This may be all patients in the family that the patient has access to, or it may be all patients that a care provider has access to, or all patients on the entire record system. In such cases, the server may choose to return an error rather than all the records.

Describe the solution you'd like
$everything should list a patient's links based on the context.

Describe alternatives you've considered
Do nothing, and leave feature as-is.

Acceptance Criteria

1. GIVEN Patient/$everything operation is installed
   AND fhir-smart is installed
   WHEN Patient/$everything is executed with an access token that carries patient/* scopes and patient_id context for patients P and Q
   AND the number of resources being return is below our configured limit for the number of resources allowed on a $everything response
   THEN a Bundle containing resources related to both Patient P and Patient Q

2. GIVEN $everything operation is installed
   AND fhir-smart is NOT installed
   WHEN Patient/$everything is executed
   AND the number of resources being return is above our configured limit for the number of resources allowed on a $everything response
   THEN return a 400 Bad Request with an OO error type of "not supported" (or too-costly?)

Note: Using fhir-smart is a good way to ensure the current patient only has access to a limited number of patients, making it more likely to stay below our configured limit. This should be tested as part of the integration tests for this feature.

Additional context
The current "configured limit" is a hardcoded to 10,000 ...should this be lowered? Should it be configurable?

[lmsurpre]

If we do implement this one, we're thinking to continue failing the request if the total number of resources is above the configured limit.

One way to address that concern would be to support "id-only" results as per
#2027

However, we think bulk export (async) is a better way to handle this type of data request in general, so moving this to the icebox for now.