Replace AbortSignal with "stop token" to rescue some aborting behavior

[cmdcolin]

Currently, the app can get bogged down if a bunch of data is being loaded, and it is difficult to abort it. We have a lot of logic about abort signals but it just never really managed to properly get wired together.

The lack of aborting can lead to the app going into 100% CPU, freezing, etc.

This PR incorporates an interesting hack called "stop tokens" implemented from this article https://yoyo-code.com/how-to-stop-synchronous-web-worker/

the hacky part

The hacky part of this is that it uses synchronous XHR, which is not deprecated but is somewhat discouraged https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest_API/Synchronous_and_Asynchronous_Requests

however, since we primarily use the sync xhr in the worker thread, it is less problematic in terms of hanging the user thread. With MainThreadRpc, we could consider not using this technique, but it is a local XHR to the URL token rather than a true sync XHR to an external resource. The article mentions it taking ~1ms

how this PR implements stop tokens

My PR here bulk replaced instances of abort signal with stopToken, rather than repurposing the "signal" prop

This could be considered a breaking change, however, the existing abortsignal support was so poor that it did not properly cover almost any use case

test out

can compare

https://jbrowse.org/code/jb2/stop_token/?config=test_data%2Fconfig_demo.json&session=share-_1RkBiZ64Y&password=MNtFu
https://jbrowse.org/code/jb2/main/?config=test_data%2Fconfig_demo.json&session=share-_1RkBiZ64Y&password=MNtFu

change the height of the track rapidly

no longer have a system to abort "fetch" calls with this PR, but this could be fixed

technically this is now disconnected from proper "fetch aborting" e.g. actually aborting downloads of large files. however

a) this never really worked anyways
b) I envision it could be re-activated by constructing a AbortController that is connected to the stop token on the worker side, and then promise.race'ing them

unclear why the abort signal system we had in place doesn't work right

note: i did not deeply investigate why the current abortsignal was not working, but i would see that it would basically like, if you change the y-height of the track, a e.g. 30+ render requests would fire off, and then like 10 seconds later, the requests would all abort at once. the proper thing would be for them to be aborting much sooner. this led me to believe that the aborts were not being prioritized, or caught up in the standard async message queue, or caught up in librpc-web-mod machinery (our rpc library)

the footnote

each time the track re-renders, it processes all the data about the features. it has been challenging to find a way to properly cache things to do less work on each re-render, but hopefully this PR helps by at least avoiding unnecessary processing after abort

[cmdcolin]

demo of changing y-axis of track repeatedly, this repeatedly re-renders the track and without aborting, on an expensive data store like snpcoverage, it can be slow

with this branch, it's fast though

Screencast.From.2024-11-18.02-11-11.mp4

with main branch, it takes a long time because it keeps trying to render old data

Screencast.From.2024-11-18.02-12-05.mp4

[cmdcolin]

I might go ahead and optimistically merge this. we can let it settle on main for a little while now that v2.17.0 is released...