chore: retry wrapper over api requests

[abilevych]

What ❔

The API retry logic for integration tests

Why ❔

It allows increase speed of test runs due to refusing the timeouts-based approach

Checklist

• PR title corresponds to the body of PR (we generate changelog entries from PRs).
• Tests for the changes have been added / updated.
• Documentation comments have been added / updated.

[github-actions]

API E2E Test Results

206 tests   206 ✅  28s ⏱️
 14 suites    0 💤
  1 files      0 ❌

Results for commit d23bd9b.

♻️ This comment has been updated with latest results.

[github-actions]

Unit Test Results

0 tests   0 ✅  0s ⏱️
0 suites  0 💤
0 files    0 ❌

Results for commit ecce757.

[github-actions]

Unit Test Results

    3 files    247 suites   8m 45s ⏱️
1 970 tests 1 969 ✅ 1 💤 0 ❌
1 996 runs  1 995 ✅ 1 💤 0 ❌

Results for commit d23bd9b.

♻️ This comment has been updated with latest results.

[github-actions]

Visit the preview URL for this PR (updated for commit d23bd9b):

• https://staging-scan-v2--pr149-qa-582-retry-wrapper-rkeuhj6s.web.app
• https://staging-storybook-scan-v2--pr149-qa-582-retry-wrapper-c2focy34.web.app

_{(expires Wed, 31 Jan 2024 09:11:36 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

_{Sign: e508f9012944951194447cb8885950b451a24403}

[pcheremu]

I'm going to make the review one more time tomorrow morning with fresh feelings. For now tests looks good and the logic is elegant. No idea if we need to worry about it or 200 iterations with low latency is preferable than longer latency with less amount of iterations. I have also noticed that (despite on some excluded tests) the total time for api tests was decreased ~ on 23% (from 17min to 13min).