AAE-28952 Fix process variable sorting

[tom-dal]

Issue link: AAE-28952

In all the filter types, the parsing of variable value has been delegated to the framework instead of using the custom extraction functions, in order to avoid having many hard-coded functions, hence the class CustomPostgreSQL is significantly reduced.

The only two remaining custom functions are:

• the function to extract the variable value as text, which is the prerequisite for all the other filters
• the function to extract the variable value as boolean, because in this case the Hibernate casting led to unexpected behaviour, so there's the need to cast at SQL level.

The filtering and sorting logic has changed, except for the root filters (Task and ProcessInstance root attributes like status, createdDate,...). Since now the framework is handling the variable parsing, the classes that implemented the conditions are now reduced and they basically implement two interfaces:

• VariableSelectionExpression: exposes a method that returns the Epression object that select either a task variable or a process variable. It is needed for both sorting and filtering.
• VariableValueFilterCondition: exposes a method that returns a predicate to filter either by a task variable or a process variable. Its implementation is an extension of VariableSelectionExpression's implementation.

Since the task and process variables filtering is obtained by adding predicates in the having clause, i.e. a group by clause is present, this leaded to wrong results when the repository was executing the count query. To fix this, the SQL window function "OVER()" has been used. To use it, a custom version of the JpaSpecificationExecutor has been implemented, which, with the aid of a the @CountOverFulWindow annotation, uses the "COUNT (*) OVER()" to count the results only when using TaskSpecification and ProcessInstanceSpecification and when there's a group by clause.

It also includes the changing in the "sort" object inner parameter regarding the process variable key in the filters request, because it was too significant for the overall logic to change it in a different PR.
processVariableKeys (array) -> processVariableKey(string)

[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

[jesty]

LGTM