AAE-22075 Fix "detaching an uninitialized collection" logs and improve task search query performance

[tom-dal]

Issue link: AAE-22075

The cause for the task search being slow when process variable have to be fetched is that Hibernate is performing N+1 queries: one query to search the tasks and N queries to fetch process variables for each task. (and also N queries to fetch candidate users and candidate groups).

A first attempt to solve the problem has been made just applying EntityGraph. Using an EntityGraph we are able to specify which field to retrieve eagerly, but the drawback is that, being the table join a cartesian product, Hibernate is not able anymore to handle pagination and sorting in the query. This way, pagination and sorting are performed in-memory which cause OOM error when the task list is huge. Additionally, even for smaller task lists that still exceed the page size, overall performance is not improved because of the large amount of data to retrieve from database.
https://stackoverflow.com/questions/75637639/spring-data-3-fetch-join-with-paging-and-specifications-is-not-working-properly

The proposed solution follows a similar approach to the one already leveraged in this other repository method

activiti-cloud/activiti-cloud-query-service/activiti-cloud-services-query/activiti-cloud-services-query-repo/src/main/java/org/activiti/cloud/services/query/app/repository/CustomizedTaskRepositoryImpl.java

Line 66 in 1527e48

JPAQuery<String> taskIdsQuery = queryFactory

It consists of performing 3 queries:

1. A first query to count all the tasks (needed for the paginated response)
2. A second query to retrieve only the Id list of the filtered tasks, with offset and limit according to paging parameters (and sorting if present)
3. A third query which retrieves the tasks by the Id list joining process variables, candidate users and candidate groups.

Additionally, the user Spring @transactional annotation ,instead of Jarkarta one, with readOnly=true attribute, should improve performance by skipping dirty-checking on entities, since DB flush is not needed.
https://medium.com/@jkha7371/is-transactional-readonly-true-a-silver-bullet-1dbf130c97f8
https://vladmihalcea.com/spring-read-only-transaction-hibernate-optimization/

Outcome of simple performance tests performed via Postman:

Jmeter tests are underway.

[sonarcloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

[igdianov]

Good work!