Allow @interfaceObject to stand in for all runtime types

[clenfest]

Rather than relying on the fact that one filteredPaths is reached, allow @interfaceObject types to intersect with all runtime types

[changeset-bot]

🦋 Changeset detected

Latest commit: 5a4863a

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

This PR includes changesets to release 7 packages

Name	Type
@apollo/composition	Patch
@apollo/gateway	Patch
@apollo/federation-internals	Patch
@apollo/query-planner	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 ready!

Name	Link
🔨 Latest commit	5a4863a
🔍 Latest deploy log	https://app.netlify.com/sites/apollo-federation-docs/deploys/669963b4b7c3bc000870dc8a
😎 Deploy Preview	https://deploy-preview-3087--apollo-federation-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[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.

[duckki]

Wouldn't it make sense to deduplicate while computing the filteredPaths here?

    const filteredPaths = newSubgraphPathInfos.map((p) => p.path.path).filter((p) => isAbstractType(p.tail.type));

Also, I'm concerned about having duplicate paths in newSubgraphPathInfos, which means we do duplicate work as well.

[clenfest]

Wouldn't it make sense to deduplicate while computing the filteredPaths here?

    const filteredPaths = newSubgraphPathInfos.map((p) => p.path.path).filter((p) => isAbstractType(p.tail.type));

Also, I'm concerned about having duplicate paths in newSubgraphPathInfos, which means we do duplicate work as well.

I'm also concerned about why the duplicate paths exist, and I'm going to keep investigating that. I think that this is an ok compromise as it should unblock the customer and we can deliver a more comprehensive fix shortly. I agree that there is something else wrong, but I think this should be safe.

[duckki]

Looks good! I could reproduce the issue with the included test. And the fix makes sense.
Also, even without duplicate paths, interface object + 2 other paths with abstract types would cause this problem, it seems. We can track the duplicate path issue separately.