Patient Export Results in duplicate data included in the Write.

[prb112]

Describe the bug
Patient Export Results in duplicate data included in the Write.

To Reproduce
Steps to reproduce the behavior:

1. Execute integration test for ExportOperationTest
2. Note the duplicate Patient data the top.

Expected behavior
From https://hl7.org/fhir/uv/bulkdata/export/index.html#response---complete-status:
Each file SHALL contain resources of only one type, but a server MAY create more than one file for each resource type returned.

Our intent is to include only the Resources in the file. Except Attachments and DocumentReferences.

Additional context
n/a

[lmsurpre]

I wonder if its worth opening a separate issue for generating a better query for this one.
Specifically, we now have a special internal "compartment" search parameter that we should be able to leverage so that we don't need to aggregate all the different compartment inclusion criteria parameters separately.

For example, we might be able to get rid of this code in PatientResourceHandler.fillChunkDataBuffer(List<String> patientIds, ReadResultDTO dto):

            List<String> compartmentSearchCriterias = CompartmentUtil.getCompartmentResourceTypeInclusionCriteria("Patient", resourceType.getSimpleName());
            if (compartmentSearchCriterias.size() > 1) {
                isDoDuplicationCheck = true;
            }
            for (String compartmentSearchCriteria : compartmentSearchCriterias) {
                HashMap<String, List<String>> queryTmpParameters = new HashMap<>();
                queryTmpParameters.putAll(queryParameters);
                queryTmpParameters.put(compartmentSearchCriteria, Arrays.asList(String.join(",", patientIds)));
                searchContext = SearchUtil.parseQueryParameters(resourceType, queryTmpParameters);

One thing that might make this difficult is that, under normal operation, a patient compartment search is only ever scoped to a single patient (whereas here we have a list of patients). A couple ideas:
A. Perform a different search for each specific patient included in the export. It would definitely be a lot more searches (i.e. more round trips to the DB), but maybe these simple searches will perform better than one giant OR query like we have now?
B. Add support (if we don't already support it) for having a logical OR on the internal compartment search parameter.

If we're able to do B, this would also help us to support user scoped SMART App Launch scopes in our AuthzPolicyEnforcementPersistenceInterceptor, which are for cases where the user has access to a set of patient compartment resources and not just their own.

[d0roppe]

verified this is now working correctly on the export.