fix(graphcache): Restore `stale` being set to `true` on blocked (but in-flight) operations

[kitten]

Note: I wasn't reasonably able to write tests for the looping protection yet that hit this particular case. Manual testing is needed!

Summary

For partial cache results, stale: false was being set when the looping protection kicks in. In simple words, if an operation is triggered twice, once as part of an unrelated query updating, causing a partial result, then again, the second trigger will create a cache result with stale: false, even if the operation would be in flight.

This PR restores stale: true being set, if we reasonably believe the operation is still in flight.

Set of changes

• Add separate stale: true override if operation is in flight

[changeset-bot[bot]]

🦋 Changeset detected

Latest commit: 8a8179088e4e1585e0e2cb7389793688fefb4cf2

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

| Name | Type | | ------------------------- | ----- | | @urql/exchange-graphcache | Patch |

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[AndrewIngram]

Seems to address the issue I was having (mentioned here: https://twitter.com/andrewingram/status/1752787499053723667), but I also haven't been able to make a simplified reproduction :/

[kitten]

The test I added should sufficiently reproduce this scenario. It doesn't quite match the manner in which this case is triggered, but it should represent both the overall conditions that triggered this bug/issue and the fix itself