Multiple (3) lines of defense against merging { __ref } objects into normalized StoreObject entities

[benjamn]

PR #7778 (first released in @apollo/client@3.4.0-beta.12) allowed merge: true to combine Reference objects (which refer to normalized StoreObject entities by ID) with non-normalized StoreObject objects.

When these mixed Reference/StoreObject merges happen (e.g. in the mergeObjects function), the StoreWriter#applyMerges method returns a Reference rather than a StoreObject, which was a new possibility not adequately handled by the calling code in PR #7778. In particular, applyMerges returning a Reference could result in calling store.merge(dataId, fields) when isReference(fields), allowing __ref properties to end up as fields in the normalized StoreObject. These stray __ref properties could later confuse the EntityStore garbage collector into not traversing the other properties of the StoreObject (because the object appears to be a Reference), potentially misidentifying any unreached references as unreachable, and thus inappropriately deleting them from the store.

This PR solves these problems in three independent ways:

1. When StoreWriter#applyMerges returns a Reference, we now assume its fields have already been updated in the store, and avoid merging the Reference object using store.merge(dataId, fields).
2. Fix EntityStore#findChildRefIds to continue traversing other properties of objects that appear to have __ref properties, just in case there has been an accidental merge.
3. Tolerate surprise Reference arguments in EntityStore#merge by converting them to their string IDs, which are well-handled by the merge method already. This shouldn't happen now thanks to 1, but provides a foolproof backup plan.

[brainkim]

No test case?

[benjamn]

@brainkim Working on a test! Let me know if you have any reproductions from your investigation yesterday, and I'll try to include them as regression tests.

[brainkim]

Sorry I don’t have a handle on the exact schema query/eviction pattern from Apollo Studio which was causing the Account to be a reference or whatever. If you’d like me to figure that out, let me know.

[benjamn]

@brainkim Studio isn't doing anything wrong! Ultimately, Studio will benefit from #7778 because they have code that previously (using AC v3.3.7) would replace an existing { __ref: "Account:..." } reference object with an incoming StoreObject. After #7778, the reference and the object should be appropriately merged in the EntityStore, with no fields lost in the process, and no stray __ref properties. However, #7778 was incomplete, containing some bugs/oversights that this PR aims to fix. With this PR is applied, I can no longer reproduce the problem locally in Studio.

[benjamn]

@brainkim Alright, I've added separate regression tests to each commit.