RFC: Return type overlap validation

[leebyron]

This alters the "Overlapping Fields Can Be Merged" validation rule to better express return type validation issues.

The existing rule has presented some false-positives in some schema where interfaces with co-variant types are commonly used. The "same return type" check doesn't remove any ambiguity.

Instead what that "same return type" check is attempting to prevent is spreading two fragments (or inline fragments) which have fields with return types where ambiguity would be introduced in the response.

In order to curb false-positives, we later changed this rule such that if two fields were known to never apply simultaneously, then we would skip the remainder of the rule.

{
  ... on Person {
    foo: fullName
  }
  ... on Pet {
    foo: petName
  }
}

However this can introduce false-negatives!

{
  ... on Person {
    foo: birthday {
      bar: year
    }
  }
  ... on Business {
    foo: location {
      bar: street
    }
  }
}

In the above example, data.foo.bar could be of type Int or type String, it's ambiguous!

This differing return type breaks some client model implementations (Fragment models) in addition to just being confusing.

For example this invalid query:

fragment A on Type {
  field: someIntField
}

fragment B on Type {
  ...A
  field: someStringField
}

Might produce the following illegal Java artifacts:

interface A {
  int getField()
}

interface B implements A {
  string getField()
}

This changes the "Overlapping Fields Can Be Merged" rule to avoid this ambiguity by comparing response shapes rather than return types.

[jjergus]

lgtm, I like this approach