UIOR-1281 Applied 'Strategies' approach for error handling of order updates

[usavkov-epam]

Purpose

https://folio-org.atlassian.net/browse/UIOR-1281

Display FY code in the error with the code budgetNotFoundForFiscalYear.

Requires: folio-org/stripes-acq-components#817

Approach

Use the ResponseErrorsContainer builder to safe and useful get error details and handle them.
Apply the "Strategy" pattern for some errors for code splitting and decoupling the code.

Screenshots

chrome_uUmN5qWzcJ.mp4

Pre-Merge Checklist

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

• I've added appropriate record to the CHANGELOG.md
• 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?
  • If any API-related changes - okapi interfaces and permissions are reviewed/changed correspondingly
  • 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 they 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?

Ideally all of the PRs involved in breaking changes would be merged in the same day to avoid breaking the folio-testing environment. Communication is paramount if that is to be achieved, especially as the number of intermodule 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.

[github-actions]

Jest Unit Test Statistics

    1 files  ±0  264 suites  ±0   6m 34s ⏱️ +3s
698 tests ±0  698 ✔️ ±0  0 💤 ±0  0 ❌ ±0 
706 runs  ±0  706 ✔️ ±0  0 💤 ±0  0 ❌ ±0 

Results for commit 54e7953. ± Comparison against base commit 8fb386b.

♻️ This comment has been updated with latest results.

[github-actions]

BigTest Unit Test Statistics

0 tests  ±0   0 ✔️ ±0   0s ⏱️ ±0s
0 suites ±0   0 💤 ±0 
0 files   ±0   0 ❌ ±0 

Results for commit 54e7953. ± Comparison against base commit 8fb386b.

♻️ This comment has been updated with latest results.

[usavkov-epam]

Tests will pass after merging of folio-org/stripes-acq-components#817

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarCloud

[zburke]

@usavkov-epam, whoops, this PR relies on ResponseErrorContainer folio-org/stripes-acq-components#817, a feature that won't be available until v5.2.0. So, actually, double whoops:

1. stripes-acq-components did not correctly bump the version on master after its last release. That means new features (like ResponseErrorContainer) will appear to be available in the 5.1.x branch but in fact they will not be available until 5.2.x.
2. Once (1) is fixed, you'll need to make a follow up here to bump the version to 5.2.0.

This works now in CI/folio-snapshot only because the version is wrong in (1) and wrong here, but as soon as you build a bundle from a production server where stripes-acq-components 5.1.x doesn't contain this feature, you'll get a build warning and this component will fail.