FINERACT-2013: Fix case-sensitive limit offset removal in count query

[Yashgoswami-ds]

Description

This PR fixes an issue in the audit pagination count query where the API returned an incorrect totalFilteredRecords value even when audit records were present.

Issue

When calling the audit API with pagination enabled:

GET /fineract-provider/api/v1/audits?paged=true&limit=5&offset=0

The API returned:

{
    "totalFilteredRecords": 0,
    "pageItems": []
}

despite audit records being available in the m_portfolio_command_source table.

Root Cause

The issue was identified in DatabaseSpecificSQLGenerator, which is responsible for generating the count query used for paginated responses.

The existing implementation attempted to remove LIMIT and OFFSET clauses using case-sensitive regular expressions:

sql.replaceAll("LIMIT \\d+", "")
   .replaceAll("OFFSET \\d+", "")

However, the SQL generated by the pagination flow used lowercase keywords:

ORDER BY aud.id DESC limit 5 offset 0

Since the regular expressions were case-sensitive, the LIMIT and OFFSET clauses were not removed from the SQL.

As a result, the generated count query still contained the pagination clauses:

SELECT COUNT(*) FROM (
    ...
    ORDER BY aud.id DESC limit 5 offset 0
) AS temp;

This caused the count query to operate on the paginated result set instead of the complete result set, leading to an incorrect totalFilteredRecords value.

Solution

Updated the regular expressions to remove LIMIT and OFFSET in a case-insensitive manner:

sql = sql.replaceAll("(?i)LIMIT\\s+\\d+", "")
        .replaceAll("(?i)OFFSET\\s+\\d+", "")
        .trim();

Using the (?i) flag ensures that SQL keywords are matched regardless of their case (LIMIT, limit, Limit, etc.), allowing the count query to be generated correctly.

Verification

The issue was reproduced and verified locally using Docker with PostgreSQL.

Before the fix

{
    "totalFilteredRecords": 0,
    "pageItems": []
}

After the fix

{
    "totalFilteredRecords": 3,
    "pageItems": [
        {
            "id": 3,
            "actionName": "CREATE",
            "entityName": "CLIENT"
        }
    ]
}

After applying the fix, the audit pagination endpoint correctly returns both the total number of matching audit records and the expected paginated results.

Testing Environment

• Apache Fineract develop branch
• Docker environment
• PostgreSQL database
• Audit pagination API