Unfortunately the parallel loading does not appear to be a bug in the client implementation. This can be verified by reproducing the behavior to make it download multiple blob content requests at the same time in our standalone version that can run inside Chrome.
Instead, I believe that the waterfalling is a result of using one I/O thread in the JCEF implementation.
Since the issue at hand is not necessarily related to parallel loading but rather that quick scrolling through variable files will get increasingly slow, we can solve the problem in an alternative way as well though: Instead of making sure new requests are started in parallel, we can also cancel the previous content request to start downloading the latest blob earlier.
This PR attempts to implement this by making use of the AbortController mechanism to abort fetch requests (so glad we don't need XMLHttpRequest for this behavior anymore lol).
We now store the abort controller for all inflight requests and abort all of them whenever we download a new content (we already have the cache in front of this condition to avoid aborting a request to the same match).
Test plan
./gradlew runIde
Connect the DevTools debugger
Open the network tab inside the DevTools
Open the Sourcegraph window in IntelliJ alt+s
Search for something that returns content results
Use the arrow down key to quickly navigate through multiple file previews
