WIP fix: concurrency issues with async requests

[katiestahl]

My plan of attack is to have a class that handles api requests and aborts them based on keys passed in on subsequent requests.

This is better than adding a debounce, since this can aid with flexibility. (user can still make changes and requests will appear instant, no need to wait for debounce)

I'm wondering about the keys, though. Those will update whenever a user makes changes to the elements. So they need to be similar enough to know that a user is still editing whatever item(s) they're editing but different enough to where, say a user is adding a fusion with two transcripts, that both requests can be made without impacting each other.

idea: maybe pass in the id of the drag n drop element and use that as a key for the abort controller?

[github-actions]

This PR is stale because it has been open 1 day(s) with no activity. Please review this PR.

[katiestahl]

I might get rid of this PR and approach this problem differently. This isn't quite working how I had hoped, and I found another solution that may get us closer to what we want. Namely, one change that will partially solve this issue is fixing the dependency array in the useEffect for the tx segment element. There's still some issues that I'm working out (ie; with this solution, if you add a new item, it will get deleted when the request comes back) but we may not need the api service I implemented in this PR