FTM: Add caching to ESContentFactoryImpl#findContentletByIdentifier to optimize queries with the publishDate parameter

[fabrizzio-dotCMS]

Parent Issue

No response

User Story

Currently, the method ESContentFactoryImpl#findContentletByIdentifier(final String identifier, final long languageId, final String variantId, final Date timeMachineDate) executes direct database queries when collections with the Time Machine feature are queried using the publishDate parameter set to a future date.

This behavior creates a vulnerability where malicious users could misuse URLs with the publishDate parameter to overload the database with unnecessary queries. To mitigate this risk, caching should be introduced for this method.

since FTM gets triggered by passing the publishDate param, add a condition to prevent FTM from getting triggered unless the publishDate is the present day including a specific time
if (publishDate == today && publishDate does not have time){
publishDate = null
}

Acceptance Criteria

•	The method leverages a caching mechanism to prevent repeated direct queries to the database.
•	The cache is invalidated automatically when changes occur to the page structure (e.g., content updates, page deletions, or publishing actions).
•	Performance improvements are observed during testing, particularly when multiple queries use the publishDate parameter with similar configurations.

Proposed Objective

Security & Privacy

Proposed Priority

Please Select

External Links... Slack Conversations, Support Tickets, Figma Designs, etc.

No response

Assumptions & Initiation Needs

No response

Quality Assurance Notes & Workarounds

No response

Sub-Tasks & Estimates

No response

[github-actions]

PRs:

• chore(FTM) Adding cache to the Queries Refs#31246 #31293
• fix(karate-test): Test breaking pipeline Do Not Merge #31399

[nollymar]

Now with FTM, each time we request a page in Live Mode, we are always sending a publish date. Please make sure we are not executing the logic related to FTM when the publish date/time is now . Consider a time lapse (I suggest 1-2 mins) in case there is a delay in the request