Fix long_callback for slow responses and small polling intervals

[sebbegg]

This fixes (#1769)

This avoids the race-condition between the long_callback interval triggers and the long callback returning slow/large payloads.
As mentioned in #1769 this PR basically does the following:

• Instead of returning the result of a long callback directly from the interval callback, the interval callback only signals that the result is ready by setting the result key and job id on an newly added "result" helper store
• When the result is ready, the interval is disabled directly (not delayed to the next interval trigger) and the user store data is cleared
• A newly added callback on the "result" store fetches the result

The code snippets for reseting the user store seem a little redundant between the should_cancel branch and the new parts of code. I'd be happy to refactor that somewhat, but wanted to keep the diff as small as possible for a start.

Contributor Checklist

• I have run the tests pytest -k long_callback locally and they passed. (refer to testing section in contributing)
• I have added tests, or extended existing tests, to cover any new features or bugs fixed in this PR

optionals

• I have added entry in the CHANGELOG.md
• If this PR needs a follow-up in dash docs, community thread, I have mentioned the relevant URLS as follows
  • this GitHub #PR number updates the dash docs
  • here is the show and tell thread in Plotly Dash community

_{Sebastian Eckweiler (sebastian.eckweiler@mercedes-benz.com), Mercedes-Benz AG on behalf of MBition GmbH (Imprint)}

[T4rk1n]

This fix is only partial, works ok for larger response. But when I tested this with the first app example from #1769, I still get infinite loops and the callback doesn't resolve and I can't cancel.

I think as long as the long callbacks requests are made via an interval component, there is bound to have issues with the polling. There is also issues with the extra components not playing well with the coming up multi page feature.

As such, we have decided to improve the long callbacks and bring them on par with regular callbacks. I am refactoring the long callback to be handled in the renderer with a request polling chain to replace the interval and extra components added by the current long callback solution. There will only be one request at time, when the fetch completes, it will either have the progress updates and restart the fetch after a timeout, or complete the initial callback outputs.

Thank you for your contribution, really helped me have a better grasp of the timing issues. I will close this PR as it's not completely fixed and would require more work while I am currently working on an overhaul of the long callbacks.