Always retain __typename during data masking

[jerelmiller]

While working on data masking for nested fragments, I stumbled on a potential pitfall with the existing solution; the data masking algorithm only retains exactly whats defined in the selection set. This means that unless __typename is defined in the fragment, this property was removed from the returned object. This is mostly ok if you're just working with the query and one level of fragments, but as you introduce nested fragments with data masking, this made it difficult to work with. If you forget to include __typename with data masking enabled, this means the from option passed to useFragment/watchFragment was invalid, so the value returned was empty. This could be solved in user-space by adding a __typename selection in the fragment, but we don't ask our users to do that with queries, nor does using watchFragment without masking behave this way today.

This PR retains __typename when present regardless of whether its present in the original document or not.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 990b655

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

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

[jerelmiller]

I removed all these __typenames from the existing tests because I want the test to more closely resemble what I expect to see from our users and how they will use this feature in their apps.

[phryneas]

Most tested change ever. I love it!