[MODFIN-352] Removed old transaction API

[damien-git]

Purpose

MODFIN-352 - Remove the old transaction API

Approach

• Removed the old endpoints
• Creating allocations and transfers is now done with a batch request - this will allow more simplifications in mod-finance-storage (the 2 endpoints to create allocations and transfers with mod-finance are preserved for now because they are still used by UI)
• Refactoring; transaction processing is now handled in 2 classes: TransactionService and TransactionApiService, with TransactionApiService handling only API requests while TransactionService can be used by any other service. The same division was applied to FiscalYearService.
• Improved error handling when creating budgets
• Updated unit tests
• Minor changes are needed in mod-finance-storage (see that related PR); this does not include API removal and simplification in mod-finance-storage

mod-finance-storage PR
integration tests PR
mod-orders PR
mod-invoice PR
ui-finance PR
ui-orders PR

Pre-Merge Checklist:

Before merging this PR, please go through the following list and take appropriate actions.

• Does this PR meet or exceed the expected quality standards?
  • Code coverage on new code is 80% or greater
  • Duplications on new code is 3% or less
  • There are no major code smells or security issues
• Does this introduce breaking changes?
  • Were any API paths or methods changed, added or removed?
  • Were there any schema changes?
  • Did any of the interface versions change?
  • Were permissions changed, added or removed?
  • Are there new interface dependencies?
  • There are no breaking changes in this PR.

If there are breaking changes, please STOP and consider the following:

• What other modules will these changes impact?
• Do JIRAs exist to update the impacted modules?
  • If not, please create them
  • Do they contain the appropriate level of detail? Which endpoints/schemas changed, etc.
  • Do they have all the appropriate links to blocked/related issues?
• Are the JIRAs under active development?
  • If not, contact the project's PO and make sure they're aware of the urgency.
• Do PRs exist for these changes?
  • If so, have they been approved?
• Did you modify code to call some additional endpoints?
  • If so, do you check that necessary module permission added in ModuleDescriptor-template.yaml file?

Ideally, all the PRs involved in breaking changes would be merged on the same day
to avoid breaking the folio-testing environment.
Communication is paramount if that is to be achieved,
especially as the number of inter-module and inter-team dependencies increase.

While it's helpful for reviewers to help identify potential problems,
ensuring that it's safe to merge is ultimately the responsibility of the PR assignee.

[SerhiiNosko]

before merge need to increate dependent UI version, will ask @usavkov-epam to apply this change

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
92.8% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[SerhiiNosko]

Thanks @damien-git for this cleanup