Rollback 2779 and confirm if RQ is less reliant on AbortControllers

[dumathane]

Proposed Change

2779 was developed to ensure our api responses weren't stepping on top of each other in our old redux environment. I'd like to confirm whether or not this is still necessary in a React Query environment. This takeaway will drive how we have to use AbortController app-wide.

Why Should We Prioritize?

This takeaway will drive how we have to use AbortController app-wide.

Coding Time Estimation

2

Testing Considerations

Follow same initial bug testing steps that existed previously on 2779:
'Tap on claim A
Realize (while it's still loading) that I meant to tap claim B
Tap back to get to the list, then tap claim B
Wait for claim B to load -- actually shows the details of claim A'

AC's:
[ ] - A branch build is created with 2779 changes disabled
[ ] - QA tests branch and is able/unable to reproduce original problem
[ ] - If unable, AbortController removal from claims/appeals can be merged, and our use of AbortControllers can be limited to edge case screens like Address Validation and Batch Refill Requests.
[ ] - If still reproducible, we'll need to close the pull request as is and use AbortControllers basically everywhere.

Checklist

• Add the relevant team label (Health, global, design system, API, Qa and Release etc.)
• Attach to ticket to the relevant Team Tech Debt Epic epic (old frontend engineering epic is no longer in use as each team is managing their code's technical debt and code upkeep work)

[rbontrager]

Verified that if you tap on claim A, wait a couple of seconds and back out while it is still loading and tap on claim b that claim b's details will display correctly. Verified in charles that the claim is loading properly as well. Approved by QA.