Use the internal patient compartment search parameter during Patient/Group export

[lmsurpre]

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.

Originally posted by @lmsurpre in #2058 (comment)

[lmsurpre]

Before this change, a compartment search like Patient/123/Basic?string=teststring (with "useStoredCompartmentParam": false) would result in SQL like:

SELECT COUNT(DISTINCT R.LOGICAL_RESOURCE_ID)
  FROM Basic_LOGICAL_RESOURCES LR
  JOIN Basic_RESOURCES R
    ON R.RESOURCE_ID = LR.CURRENT_RESOURCE_ID
   AND R.IS_DELETED = 'N'
  JOIN Basic_TOKEN_VALUES_V AS param0
    ON ((param0.PARAMETER_NAME_ID = 30000 AND param0.TOKEN_VALUE = ? AND param0.CODE_SYSTEM_ID = 30001))
   AND LR.LOGICAL_RESOURCE_ID = param0.LOGICAL_RESOURCE_ID 
  JOIN Basic_STR_VALUES  AS param1
    ON (param1.PARAMETER_NAME_ID = 20006 AND (param1.STR_VALUE_LCASE LIKE ? ESCAPE '+'))
   AND LR.LOGICAL_RESOURCE_ID = param1.LOGICAL_RESOURCE_ID

searchArgs=[123, teststring%]

After this change, the same query now looks like:

SELECT COUNT(DISTINCT R.LOGICAL_RESOURCE_ID)  
  FROM Basic_LOGICAL_RESOURCES LR  
  JOIN Basic_RESOURCES R ON R.RESOURCE_ID = LR.CURRENT_RESOURCE_ID  
   AND R.IS_DELETED = 'N'  
  JOIN Basic_TOKEN_VALUES_V  AS param0 
    ON ((param0.PARAMETER_NAME_ID = 30000 AND param0.TOKEN_VALUE IN (?) AND param0.CODE_SYSTEM_ID = 30001)) 
   AND LR.LOGICAL_RESOURCE_ID = param0.LOGICAL_RESOURCE_ID 
  JOIN Basic_STR_VALUES  AS param1 
    ON (param1.PARAMETER_NAME_ID = 20006 AND (param1.STR_VALUE_LCASE LIKE ? ESCAPE '+')) 
   AND LR.LOGICAL_RESOURCE_ID = param1.LOGICAL_RESOURCE_ID

searchArgs=[123, teststring%]

Or, if "useStoredCompartmentParam": true and the common_token_value exists:

SELECT COUNT(DISTINCT R.LOGICAL_RESOURCE_ID)  
  FROM Basic_LOGICAL_RESOURCES LR  
  JOIN Basic_RESOURCES R ON R.RESOURCE_ID = LR.CURRENT_RESOURCE_ID  
   AND R.IS_DELETED = 'N'  
  JOIN Basic_TOKEN_VALUES_V  AS param0 
    ON ((param0.PARAMETER_NAME_ID = 40000 AND param0.COMMON_TOKEN_VALUE_ID IN (100001))) 
   AND LR.LOGICAL_RESOURCE_ID = param0.LOGICAL_RESOURCE_ID JOIN Basic_STR_VALUES  AS param1 
    ON (param1.PARAMETER_NAME_ID = 20006 AND (param1.STR_VALUE_LCASE LIKE ? ESCAPE '+')) 
   AND LR.LOGICAL_RESOURCE_ID = param1.LOGICAL_RESOURCE_ID

searchArgs=[teststring%]

Basically, we replace the first = from param0.TOKEN_VALUE = ? AND param0.CODE_SYSTEM_ID = 30001 with the IN construct.
Additionally I noticed that, even when using COMMON_TOKEN_VALUE, we were still including the TOKEN_VALUE in the where clause...I think that should already be wrapped up in the COMMON_TOKEN_VALUE and so I removed that part.
See the diff on JDBCQueryBuilder.processInclusionCriteria() for more detail.

[lmsurpre]

The payoff here is that we can now perform queries against multiple patient compartments at once (for example for Patient export or for scoping a query for security/privacy reasons). Here is the above query, but scoped to patient compartments 123 and xyz.
Note that Patient/123 exists, but Patient/xyz does not, and so it falls back to the "old way":

SELECT COUNT(DISTINCT R.LOGICAL_RESOURCE_ID)  
  FROM Basic_LOGICAL_RESOURCES LR  
  JOIN Basic_RESOURCES R ON R.RESOURCE_ID = LR.CURRENT_RESOURCE_ID  
   AND R.IS_DELETED = 'N'  
  JOIN Basic_TOKEN_VALUES_V  AS param0 
    ON ((param0.PARAMETER_NAME_ID = 20017 AND param0.TOKEN_VALUE IN (?, ?) AND param0.CODE_SYSTEM_ID = 20020)) 
   AND LR.LOGICAL_RESOURCE_ID = param0.LOGICAL_RESOURCE_ID 
  JOIN Basic_STR_VALUES  AS param1 
    ON (param1.PARAMETER_NAME_ID = 20006 AND (param1.STR_VALUE_LCASE LIKE ? ESCAPE '+')) 
   AND LR.LOGICAL_RESOURCE_ID = param1.LOGICAL_RESOURCE_ID

searchArgs=[123, xyz, teststring%]

[d0roppe]

Tested bulk data export for both patient compartment and group. Things are working as expected.

[prb112]

Closing Per Dag's Comment. I've done the same, and things are working as expected for me too.