Fix not using @join__type for fields with no @join__field (#2654)

When a field is defined in all the subgraphs in which its type is
defined (typically the case for value types) and the field has nothing
specific (no `@requires`, `@provides`, `@override`, ...), then we
don't mark it in the supergraph with a `@join__field`. It's not
really needed, and this keeps supergraphs smaller.

But the code extracting subgraphs from supergraph was not handling
that case gracefully, and it was instead trying to add such fields
to all the subgraphs. This didn't break anything because when a
subgraph didn't had the type, the code was still giving up on adding
the field, but for supergraph with a fair number of subgraphs, this
led to a lot of busy work, making the extraction code slower than
it needed to be.

This commit fix that issue.

Note that a reason this probably occured is that the extraction
is trying to handle all versions of supergraphs with the same code,
but fed1 supergraphs and fed2 supergraphs have actually a fair number
of differences, and trying to handle both with the same code is,
in hindsight, a bit confusing and we should clean it up. Leaving
this as a follow-up however.

Author: Sylvain Lebresne

.changeset/violet-rice-cheer.md

@@ -0,0 +1,9 @@
+---
+"@apollo/federation-internals": patch
+---
+
+Fix unnecessary busy work in the code extracting subgraphs from supergraphs. This code is executing when a new
+supergraph is deployed, and can impact gateway clients when it runs. This is often not a problem, but for
+large supergraphs with lots of subgraphs, an obvious inefficiency could make the code take much longer than
+it should have.
+  

internals-js/src/extractSubgraphsFromSupergraph.ts

@@ -328,15 +328,46 @@ export function extractSubgraphsFromSupergraph(supergraph: Schema): Subgraphs {
           }
           // Fall-through on purpose.
         case 'InputObjectType':
+          const typeApplications = type.appliedDirectivesOf(typeDirective);
+          // Note that we can have more that one `@join__type` for a given graph if there is multiple keys, so we collect
+          // the actual set of subgraphs defining the type.
+          const subgraphsDefiningType: Subgraph[] = [];
+          for (const app of typeApplications) {
+            const subgraph = subgraphs.get(graphEnumNameToSubgraphName.get(app.arguments().graph)!)!;
+            if (!subgraphsDefiningType.includes(subgraph)) {
+              subgraphsDefiningType.push(subgraph);
+            }
+          }
+
           for (const field of type.fields()) {
             const fieldApplications = field.appliedDirectivesOf(fieldDirective);
             if (!fieldApplications.length) {
-              // The meaning of having no join__field depends on whether the parent type has a join__owner.
-              // If it does, it means the field is only on that owner subgraph. Otherwise, we kind of don't
-              // know, so we add it to all subgraphs that have the parent type and, if the field base type
-              // is a named type, know that field type.
+              // Where there is no join__field, there is roughly 3 main cases:
+              // 1. if the type has an `@join__owner` directive (old fed1 supergraph), then the field belong to that owner subgraph.
+              // 2. otherwise, if the type has some `@join__type` directives (which it will have in post-"fed1" supergraph), then
+              //    the field is in all the supergraph in which the type is.
+              // 2. otherwise,  we kind of don't know, so we add it to all subgraphs that have the parent type and, if the
+              //    field base type is a named type, know that field type. Note that this last case only happens for old fed1
+              //    supergraphs which were lacking information and force a bit of guessing. All fed2 generated supergraph
+              //    use `@join__type` systematically on all types, and will always be case 2.
               const ownerApplications = ownerDirective ? type.appliedDirectivesOf(ownerDirective) : [];
-              if (!ownerApplications.length) {
+              if (ownerApplications.length > 0) {
+                assert(ownerApplications.length == 1, () => `Found multiple join__owner directives on type ${type}`)
+                const subgraph = subgraphs.get(graphEnumNameToSubgraphName.get(ownerApplications[0].arguments().graph)!)!;
+                const subgraphField = addSubgraphField(field, subgraph);
+                assert(subgraphField, () => `Found join__owner directive on ${type} but no corresponding join__type`);
+                continue;
+              }
+
+              if (subgraphsDefiningType.length > 0) {
+                const isShareable = isObjectType(type) && subgraphsDefiningType.length > 1;
+                for (const subgraph of subgraphsDefiningType) {
+                  const subgraphField = addSubgraphField(field, subgraph);
+                  if (subgraphField && isShareable) {
+                    subgraphField.applyDirective(subgraph.metadata().shareableDirective());
+                  }
+                }
+              } else {
                 const fieldBaseType = baseType(field.type!);
                 const isShareable = isObjectType(type) && subgraphs.values().filter((s) => s.schema.type(type.name)).length > 1;
                 for (const subgraph of subgraphs) {
@@ -347,11 +378,6 @@ export function extractSubgraphsFromSupergraph(supergraph: Schema): Subgraphs {
                     }
                   }
                 }
-              } else {
-                assert(ownerApplications.length == 1, () => `Found multiple join__owner directives on type ${type}`)
-                const subgraph = subgraphs.get(graphEnumNameToSubgraphName.get(ownerApplications[0].arguments().graph)!)!;
-                const subgraphField = addSubgraphField(field, subgraph);
-                assert(subgraphField, () => `Found join__owner directive on ${type} but no corresponding join__type`);
               }
             } else {
               const isShareable = isObjectType(type)