(core) - Avoid dispatching an operation for already active cache-first/only operations

[kitten]

Summary

Previously, in #1515 we merged the groundwork for making identical operations that are run concurrently more intuitive. Namely, when an active source is active multiple times then the sources that newly become active will have the last known result replayed. (There was one bug in there that's fixed in here; See "Set of changes")

We can use the same principle to make concurrent operations in general more intuitive. While it'd seem to make sense to create some kind of "result cache" that prevents unnecessary work, we now have the foundation that we need to make this intuitive and seamless, on top of existing logic.

With these changes applied we will now not dispatch a new operation on the Client and instead use the replayed result when the request policy isn't network-only or cache-and-network (since these intuitively instruct the cache to fetch). Instead when cache-first or cache-only are used and a replay result exists, the Client will only issue the replayed result and will not do anything else.

Set of changes

• Fix an issue where a reused (but previously unsubscribed from) replayOnStart source wouldn't reset the replay value to undefined.
• Create a 'pre' | 'post' mode for replayOnStart where 'pre' is the existing behaviour and 'post' issues the start() if no replay result is available
• Update tests to account for the new difference

[changeset-bot]

🦋 Changeset detected

Latest commit: b6a6cea

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

This PR includes changesets to release 1 package

Name	Type
@urql/core	Minor

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