Union types are not rebuilt properly from the supergraph, creating potential runtime issues

[pcmanus]

Union types are merged by composition, but we don't preserve information about which subgraph declares which types of the union in the supergraph (very much an oversight). As the result, the query planner does not know which subgraph declares which type as part of the union, and that can lead to send invalid queries to a subgraph (which are thus rejected at runtime).

Consider the following example:

# subgraph `S1`
type Query {
  u: U
}

union U = A | B

type A @key(fields: "id") {
  id: ID!
  a1: Int
}

type B {
  id: ID!
  b: Int
}

type C  @key(fields: "id") {
  id: ID!
  c1: Int
}

# subgraph `S2` 
type Query {
  otherQuery: U
}

union U = A | C

type A @key(fields: "id") {
  id: ID!
  a2: Int
}

type C @key(fields: "id") {
  id: ID!
  c2: Int
}

The definition of interface U in the supergraph ends up as:

union U = A | B | C

and so the following query is valid (on the supergraph API):

query {
  u {
    ... on C {
      c1
    }
  }
}

However, the query planner currently generate the following fetch:

Fetch(service: "S1") {
  {
    u {
      __typename
     ... on C {
       c1
     }
    }
  }
},

which is not valid GraphQL because for S1, union U does not contains C and so the subgraph would reject the query with an error looking like:

Fragment cannot be spread here as objects of type "U" can never be of type "C".

But the underlying reason this happens is that the composed supergraph does not preserve the information regarding which subgraphs defined which types for union U. As a result, the "view" of the subgraph that the query planner has is that both S1 and S2 declares U as A | B | C, which is incorrect.

[pcmanus]

Note that fixing this require a bump of the underlying "join spec" used by supergraphs (which is ok, that's why we have versioning in place, but does mean that the supergraph generated by whichever release this goes in won't be readable by older versions).