Avoid voiding result.data in ObservableQuery#getCurrentResult when !diff.complete

[benjamn]

PR #8422 (released in @apollo/client@3.4.0-rc.15) attempted to solve issue #7978 (reported by @dylanwulf) by relying on queryInfo.getDiff() to obtain results appropriate for the current variables, rather than relying on the lastResult stored by the ObservableQuery (which may have been obtained using different variables).

While this solution appeared to resolve #7978, it introduced a new bug (reported in #8620 by @maxsalven) because the following code now runs unconditionally:

apollo-client/src/core/ObservableQuery.ts

Lines 205 to 208 in bd03ff0

	result.data = (
	diff.complete ||
	this.options.returnPartialData
	) ? diff.result : void 0;

Whenever !(diff.complete || this.options.returnPartialData), this code clobbers result.data with void 0, even though result.data might provide useful information. In the case of #8620, that clobbered information is the missing network result for the A query.

Ideally, we should leave result.data unmodified except when diff.result is used, as follows:

apollo-client/src/core/ObservableQuery.ts

Lines 205 to 207 in 1b1f085

	if (diff.complete || this.options.returnPartialData) {
	result.data = diff.result;
	}

This change helps with issue #8620, but introduces some new test failures, because some of the result.data objects that are now delivered (instead of void 0) were obtained using different/stale variables than the current this.options.variables. In other words, these test failures can be prevented if we finish fixing #7978, because the previous result will be appropriately ignored by getCurrentResult when the variables have changed.

The rest of the commits in this PR fix those tests by tracking a snapshot of the original variables associated with the last result, so the getCurrentResult method can avoid using this.last.result if this.last.variables no longer match this.options.variables.

I also considered reverting PR #8422 and building back up to a better solution for #7978, but #8422 wasn't all bad, and I was able to make everything work more easily and cleanly with the current approach.

[hwillson]

Great fix @benjamn!

[brainkim]

My small and smooth brain is unable to understand how methods like getLastResult(), resetLastResult() and isDifferentFromLastResult() are supposed to be used. How would we communicate their purpose to users who directly call client.watchQuery()?

Nevertheless, if this fixes issues for users, I guess it should be merged.

[brainkim]

LGTM so I can rebase against this in #8596