UISACQCOMP-219 Create common utilities for managing response errors

[usavkov-epam]

Purpose

https://folio-org.atlassian.net/browse/UISACQCOMP-219

• The ResponseErrorsContainer utility is designed to handle and manage errors that arise from HTTP responses in a structured way.
• It standardizes errors into a manageable format, regardless of whether the error comes in a specific format or is generic/unknown.
• It allows easy retrieval of error messages, codes, and handling via various strategies to streamline error processing.
• The utility simplifies working with multiple errors by storing them in a structured format, such as a Map.

Approach

1. The class encapsulates the original HTTP response and parses the response body, particularly focusing on extracting errors.
2. It provides both static and instance methods to:
   • Parse errors, normalize them, and store them in a map for quick access.
   • Offer error retrieval by code or default to the first error if no specific code is provided.
   • Enable integration with external strategies for customized error handling.
3. It supports asynchronous creation of error containers, making it adaptable to promise-based response handling.
4. The utility normalizes different types of errors (e.g., strings, JSON objects) into a consistent structure using the ResponseErrorContainer class for downstream usage.

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  214 suites  +2   3m 58s ⏱️ -5s
556 tests +20  554 ✔️ +20  2 💤 ±0  0 ❌ ±0 
559 runs  +20  557 ✔️ +20  2 💤 ±0  0 ❌ ±0 

Results for commit fb67eb2. ± Comparison against base commit d0dde18.

♻️ 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 fb67eb2. ± Comparison against base commit d0dde18.

♻️ This comment has been updated with latest results.

[alisher-epam]

It is not a big deal but you could change the order 1 line up ⬆️

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarCloud