Panel: abort overlapping Fiber requests

[distantnative]

Description

Summary of changes

• Abort previous Panel Fiber request if it is still running when new gets started

Reasoning

• Navigating to a slow view A and immediately clicking on another Panel link B will first go to B but then jump to A once that requests finishes. (Slower navigation requests still go through even if already navigated elsewhere #6536) that's clearly unwanted.
• However, not sure if there aren't other cases running through panel.open() where we want concurrent requests.

[bastianallgeier]

Suggestion I would probably call it abortController to make instantly clear what this is controlling.

[bastianallgeier]

Looking at the code, I was wondering if we could put that abort logic into the request.js module in a good way. Maybe even with an option to make requests abortable by demand via an option? That option could be set to false by default to keep the current concurrent behaviour, but for the open request we could then set it to true.

[distantnative]

@bastianallgeier I think the deeper we move it, the trickier it could be to differentiate between which requests should cancel each other out. I think a pure boolean wouldn't work, e.g. search requests should abort each other and view requests should abort each other, but a search request should not abort a view request probably.

[bastianallgeier]

You are right, let's keep it simple and specific to each request type.

[distantnative]

@bastianallgeier I am still a bit worried whether this PR is already too far down the chain and canceling out panel requests that shouldn't cancel each other out. What's your thoughts there?

[bastianallgeier]

It's definitely possible that we miss something here. But to be honest, I really don't know how to properly test that. Maybe we should move this into the alpha? We could also think about introducing a bunch of slow loading models in our lab setup to emulate slow responses in the panel.