FINERACT-1659: Prevent duplicate savings interest posting in same period

[sidshas03]

Description

This PR fixes the duplicate interest posting issue reported in FINERACT-1659, where the Post Interest job could post interest multiple times for the same savings account within the same posting period.

What changed

• Added a safeguard in SavingsSchedularInterestPoster to skip accounts where interest has already been posted for the current period, by comparing interestPostedTillDate with the current business date.
• Updated the transaction isolation level to SERIALIZABLE to prevent duplicate postings caused by race conditions during parallel scheduler runs.

Tests

Added two integration tests to validate the behavior:

• testPostInterestPreventsDuplicateOnSameDay
  Ensures running the job twice on the same day results in only one interest posting.
• testPostInterestSkipsCurrentPeriodButAllowsNewPeriod
  Ensures the job skips reposting within the current period, while still allowing postings in a new period.

Expected outcome

• Running the Post Interest job multiple times within the same posting period will not create duplicate transactions, and the savings account balance remains unchanged after subsequent runs.

[adamsaghy]

While the SERIALIZABLE here might be better than the READ_UNCOMMITTED, i dont think we are addressing the underlying issue properly.

I would rather recommend a different approach:

• Is it possible to ensure no two SavingsSchedularInterestPoster got the very same savings account? If we can ensure no two parallel executed postInterest work on the very same savings account, i see no reason why would any double posting and we dont need to enforce SERIALIZABLE isolation which usually means strict and heavy locking of the resource which does not help the performance.

Alternative solution:

• Is it possible to introduce constraints which ensure no two interest to be posted on the very same date of the very same savings account? We can even build retry strategy too based on this constraints:
• Read savings account -> post interest -> if fails, refetch the savings account and check again whether interest needed to be posted.

It might go beyond the scope of the original story, but to be frank, this would be the proper way to do it.

TLDR: 1 savings account should be processed by 1 thread entirely and avoid situations where 1 savings account might be processed by many threads.

[adamsaghy]

@sidshas03

Execution failed for task ':integration-tests:spotlessJavaCheck'.
> The following files had format violations:
      src/test/java/org/apache/fineract/integrationtests/SavingsInterestPostingTest.java
          @@ -523,8 +523,7 @@
           ············schedulerJobHelper.executeAndAwaitJob(POST_INTEREST_JOB_NAME);
           
           ············List<HashMap>·txsAfterFirstPeriod·=·getInterestTransactions(accountId);
          -············Assertions.assertEquals(1,·txsAfterFirstPeriod.size(),
          -····················"Expected·exactly·one·interest·transaction·after·first·posting·period");
          +············Assertions.assertEquals(1,·txsAfterFirstPeriod.size(),·"Expected·exactly·one·interest·transaction·after·first·posting·period");
           
           ············HashMap·summaryAfterFirstPeriod·=·savingsAccountHelper.getSavingsSummary(accountId);
           ············BigDecimal·balanceAfterFirstPeriod·=·BigDecimal.valueOf(((Double)·summaryAfterFirstPeriod.get("accountBalance")));
  Run './gradlew :integration-tests:spotlessApply' to fix these violations.

[adamsaghy]

Please review the failing test cases