Allow refetchQueries to refetch observerless queries (again)

[benjamn]

This PR is a follow-up to PR #8825, which was first released in Apollo Client v3.4.14. As a number of commenters have reported in issue #5419, it appears we did not completely fix the problem, so this PR attempts to finish that work.

To reiterate the motivation behind #8825: an ObservableQuery redelivers the most recent result/error to new subscribers, so it is not completely pointless to refetch an ObservableQuery that (currently) has no subscribers.

However, any ObservableQuery in standby mode (whose options.fetchPolicy is standby) should still be excluded from "active" status as far as refetchQueries is concerned. This logic handles useLazyQuery queries that have not yet been executed, since they start out in standby mode until called.

[benjamn]

In other words, I now believe I was wrong about #8825 (comment), and the active shorthand should only mean "not standby" with no additional requirement that the observables currently have observers/subscribers.

[benjamn]

On third thought, with the exception of @Off2Race in #5419 (comment), I doubt most of the people reporting problems in #5419 are using the refetchQueries: "active" shorthand when performing mutations, so this PR might not be the answer for them.

Instead, the general theme in #5419 seems to be the unpredictable interaction between refetchQueries and recently-unmounted components/queries. Specifically, there seems to be a desire for refetching an unmounted query to have the effect of marking it for refetching whenever it gets mounted again.

The trouble with that idea, as I understand it, is that React gives us no way to recover the old ObservableQuery state for a re-mounted component, since we can't even tell whether two component renderings represent the same logical component (especially if the component moves around in the document between mountings).

I'll have to keep thinking about this, but I wanted to share my current thinking in case anyone has ideas.

[jerelmiller]

Hey @benjamn 👋

I know you wrote this PR a couple years ago, but after discussing with the rest of the team, we are going to hold off on making changes to the existing behavior for 3.x and revisit this API in its entirety for a future major version. As such, I'm going to close this. Thanks for your exploration and explanations here which helped us arrive at this conclusion!