perf: query in-memory filtering as predicate [DHIS2-18041]

[jbee]

Summary

Refactors the matching within the in-memory query engine to run the matching in 2 steps

1. compute a Predicate matcher function for each Filter
2. test each object candidate using the Predicate

This is an important performance improvement because...

1. the 1st step which contains multiple lookups is only done once (as compared to before where is was done for each object candidate).
2. the matching itself does not create temporary collections. The algorithm before the refactoring would matrix multiply nested paths with collections and then test each result. For example, a path like x.y.z with x and y being collections of size N and M would result in a intermediate collection of size N * M if z objects. These then each would be tested against the filter. This would happen for each object candidate tested. But building the intermediate collections is entirely unnecessary. The same can be done using "exists any" logic testing along the path instead. So in this example the code checks: exists and e in N where there exists any e in M where z matches the test.

Automatic Testing

There are countless tests directly and indirectly testing this. No new tests were added.

Manual Testing

Would be any sort of metadata API query using a filter: ?filter=...

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud