fix handling of __typename optimizations

[dariuszkuc]

Fixes handling of a __typename selection during query planning process.

When expanding fragments we were keeping references to the same Fields regardless where those fragments appeared in our original selection set. This was generally fine as in most cases we would have same inline fragment selection sets across whole operation but was causing problems when we were applying another optimization by collapsing those expanded inline fragments creating a new selection set. As a result, if any single field selection (within that fragment) would perform optimization around the usage of __typename, ALL occurrences of that field selection would get that optimization as well. See example below

foo {
  f1 {
    ... on Bar {
      __typename
      ...onBar # will be collapsed and sub selections will optimize __typename
    }
  }
  f2 {
    ...onBar # sub selections will get __typename optimization from above
  }
}

fragment onBar on Bar {
  b
  c
}

[changeset-bot]

🦋 Changeset detected

Latest commit: f168c7b

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

This PR includes changesets to release 7 packages

Name	Type
@apollo/query-planner	Patch
@apollo/federation-internals	Patch
@apollo/gateway	Patch
@apollo/composition	Patch
@apollo/query-graphs	Patch
@apollo/subgraph	Patch
apollo-federation-integration-testsuite	Patch

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

[netlify]

✅ Deploy Preview for apollo-federation-docs canceled.

Name	Link
🔨 Latest commit	f168c7b
🔍 Latest deploy log	https://app.netlify.com/sites/apollo-federation-docs/deploys/66f5c6f73af5680008ce4533

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

[sachindshinde]

Pushed up some changes in this commit to fix some things, other than that looks good to me.

To summarize:

1. In the changes to optimizeSiblingTypenames(), a new variable named firstFieldIndex was being set, that is expected to be the index of the first non-optimized-away field in updatedSelections (which is only populated if there are any selections to update, i.e. if a __typename field is found, or a field/inline fragment's selection set was recursively updated). The code before was not setting firstFieldIndex if updatedSelections was falsy, i.e. if no selections to update had been encountered by that point in the loop. I've updated optimizeSiblingTypenames() to always set firstFieldIndex when firstFieldSelection is set (regardless of whether updatedSelections actually gets populated).
2. I've moved the Field-copying code inside FieldSelection.withAttachment() into a new Field.copy() method that's next to the other Field.with*() methods. The idea here is that if someone adds an optional argument to Field's constructor, it would be easier to not accidentally omit this argument copying if the methods that copy were inside Field (IMO we probably shouldn't be using optional arguments in those constructors to begin with, but that's not something to worry about dealing with now).
   • There's also a slight change here, in that we copy the attachments from the old field as well. This is for if we ever decide to add more attachments in the future, and shouldn't affect the case of the typename attachment (since we don't try to sibling-optimize the results of a sibling-optimized query).
3. I've updated comments for the attachement->attachment rename.