Support disease filter on results CSV download

[mpbrown]

BACKEND PULL REQUEST

Related Issue

• Resolves [BUG] Fix download csv test results filters  #7948

Changes Proposed

• Adds support for disease filter parameter on the results CSV download

Additional Information

• The main results list page and the csv download use different but very similar queries and search filters.
• The key difference between the two is that the csv download has some additional data from the test event AOE responses while the main results list page does not.
• Main results page calls the query mapping to ResultResolver.resultsPage which then calls ResultService.getFacilityResults or ResultService.getOrganizationResults. These service methods then call ResultRepository.findAll and pass in a JPA Specification<Results> that is created with the Jakarta criteria builder in buildResultSearchFilter.
• The CSV download calls the query mapping to TestResultResolver.testResultsPage which then calls TestOrderService.getOrganizationTestEventsResults or TestOrderService.getFacilityTestEventsResults. These service methods then call TestEventRepository.findAll and pass in a JPA Specification<TestEvent> that is created with the Jakarta criteria builder in buildTestEventSearchFilter.
• For both buildTestEventSearchFilter and buildResultSearchFilter there is fairly identical logic for applying the filters on the joins.
• A future ticket should refactor some of this to ideally use one query and support both use cases whether or not it requires the additional AOE data.

GraphQL backwards compatibility

• I looked over this wiki section regarding GQL backwards compatibility and I believe since we are only adding a new optional field that there will not be any issues with including both frontend and backend changes in the same PR.

Testing

• Deployed on dev5

[sonarqubecloud]

Quality Gate failed

Failed conditions
B Maintainability Rating on New Code (required ≥ A)

See analysis details on SonarCloud

Catch issues before they fail your Quality Gate with our IDE extension SonarLint

[mpbrown]

Since these queries are already called out as candidates for refactoring in the future, I think we could probably be safe with "Accepting" the SonarCloud issues that identify the method using 8 parameters instead of 8. But let me know if anyone would prefer this addressed in this PR instead of the follow up refactor ticket.

[mpbrown]

Added a parameter to pass in a specific site so that one of the tests can use the global instance variable facility site rather than a new disease specific facility created below

[emyl3]

LGTM! tested on dev5 and filters worked as expected!