perf(engine): use EXISTS for task authorization queries

[hauptmedia]

Summary

Backports the CIBSeven task-query authorization SQL optimization to Operaton.

The old task query joins ACT_RU_AUTHORIZATION into the main task result set and then checks AUTH.RESOURCE_ID_ IS NOT NULL in the contextual authorization block. This patch keeps the existing contextual authorization semantics but evaluates task-query authorizations through an EXISTS subquery instead of the main join. The goal is to avoid inflating the task result set during task list and task count queries.

What changes

• Adds AuthorizationEntity.authCheckForTaskQueryWithExistsClause.
• Allows authCheckJoinWithoutOnClauseWithBinding to be reused without emitting inner join / left join when it is embedded in the EXISTS subquery.
• Removes the main AUTH join from Task.xml for non-revoke task queries.
• Enables the new EXISTS path only for task queries via applyAuthorizationCheckForTaskQueryFast.
• Explicitly keeps variable-instance and statistics mappings on the old join behavior.

Source attribution

Backported from CIBSeven:

• Source commit: fd12ffc2e422683ec9e41ccb82ff3bafe4d8b19c
• Source PR: improve(engine): use fast authentication check with EXISTS clause in the task-count and task-selection queries (used inside CIB seven webclient taskslist) cibseven/cibseven#151
• Source title: improve(engine): use fast authentication check with EXISTS clause in the task-count and task-selection queries
• Original author: vladgrind <156691737+vladgrind@users.noreply.github.com>

Operaton adaptation:

• Mapper references adapted from org.cibseven to org.operaton.
• Kept the PR as Draft because this is security-sensitive authorization SQL and should get maintainer review before merge.

Reviewer notes

This PR intentionally changes SQL shape, not authorization rules. The acceptance question is whether the generated SQL is equivalent across Operaton's supported databases while improving task-list/count performance.

Important review points:

• Non-revoke task authorization now uses EXISTS (...) over ACT_RU_AUTHORIZATION instead of a main AUTH join.
• Revoke authorization mode still uses the existing authorizationCheck CASE path.
• Case-instance handling remains tied to applyAuthorizationCheckForCaseInstances.
• The MSSQL-specific authorization include remains in use through authCheckMethodSuffix.

Verification

• ./mvnw -pl engine -Dtest=TaskAuthorizationTest,TaskCountByCandidateGroupAuthorizationTest,VariableInstanceAuthorizationTest,ActivityStatisticsAuthorizationTest test -Dskip.frontend.build=true
• Result: 344 tests, 0 failures, 0 errors

[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

[javahippie]

This change brings performance improvements in theory, but I would like to see benchmarks or user experience reports before merging this, especially because it removes previous work which concerned performance (see inline comment)

[hauptmedia]

I ran a focused benchmark for the authorization SQL change, specifically against the MySQL/MariaDB concern from the inline review.

Compared commit fe9fc07389 from this PR against its direct parent bd6f532b87, so the measurement isolates this PR's SQL shape change.

Setup:

• Databases: MySQL 8.4 and MariaDB 10.11 via the existing qa/test-database-container/docker-compose.yaml
• Data set: 5,000 running process-bound user tasks
• Authorization setup: authenticated user + 10 groups, 22 matching TASK/READ authorizations
• Per operation: 50 warmup iterations, 300 measured iterations
• Measured operations: TaskQuery.listPage(0, 15), ordered listPage(0, 15), and TaskQuery.count()

Results, average duration per query:

DB	Operation	Baseline bd6f532b87	PR fe9fc07389	Speedup
MySQL	listPage	132.305 ms	19.652 ms	6.73x
MySQL	ordered listPage	129.500 ms	19.285 ms	6.72x
MySQL	count	27.415 ms	10.921 ms	2.51x
MariaDB	listPage	273.394 ms	29.222 ms	9.36x
MariaDB	ordered listPage	271.863 ms	29.305 ms	9.28x
MariaDB	count	48.538 ms	8.017 ms	6.05x

P95 showed the same direction:

DB	Operation	Baseline p95	PR p95	Speedup
MySQL	listPage	144.174 ms	21.681 ms	6.65x
MySQL	ordered listPage	143.805 ms	20.990 ms	6.85x
MySQL	count	30.177 ms	15.142 ms	1.99x
MariaDB	listPage	294.333 ms	30.338 ms	9.70x
MariaDB	ordered listPage	303.839 ms	31.002 ms	9.80x
MariaDB	count	50.237 ms	8.967 ms	5.60x

So even though the new EXISTS subquery uses AUTH.RESOURCE_ID_ IN (RES.ID_, D.KEY_, '*'), the overall query shape is substantially faster on both MySQL and MariaDB in this task-query authorization scenario. The result-set inflation from the old main authorization join appears to dominate the previous MySQL/MariaDB-specific OR optimization here.

[hauptmedia]

Follow-up: I also ran the same focused benchmark against PostgreSQL.

Compared commit fe9fc07389 from this PR against its direct parent bd6f532b87, using the same benchmark setup as above.

Setup:

• Database: PostgreSQL 14 via the existing qa/test-database-container/docker-compose.yaml
• Data set: 5,000 running process-bound user tasks
• Authorization setup: authenticated user + 10 groups, 22 matching TASK/READ authorizations
• Per operation: 50 warmup iterations, 300 measured iterations
• Measured operations: TaskQuery.listPage(0, 15), ordered listPage(0, 15), and TaskQuery.count()

Results, average duration per query:

DB	Operation	Baseline bd6f532b87	PR fe9fc07389	Speedup
PostgreSQL	listPage	193.967 ms	14.073 ms	13.78x
PostgreSQL	ordered listPage	144.124 ms	10.073 ms	14.31x
PostgreSQL	count	19.371 ms	13.695 ms	1.41x

P95:

DB	Operation	Baseline p95	PR p95	Speedup
PostgreSQL	listPage	221.502 ms	18.561 ms	11.93x
PostgreSQL	ordered listPage	186.381 ms	13.553 ms	13.75x
PostgreSQL	count	23.941 ms	20.516 ms	1.17x

PostgreSQL shows the same overall direction: the new EXISTS query shape is much faster for task list queries, and still modestly faster for the count query in this scenario.

[kthoms]

The measurements you did are impressive. From what I read from the change the risk is limited and non-breaking. I would like to have that change. We are in early 2.2 state, so users have also the chance to report.

Beyond that, could you share the benchmark tool? Would be valuable to have it and run frequently on defined hardware.

[hauptmedia]

i added the test program used in this PR #3202
We can further discuss it there.

[hauptmedia]

Feel free to merge, could make sense to include it in the 2.2.0-M1 release