`enable_typename_discriminated_unions` feature bug - abstract inline fragment selections incorrectly merged onto concrete union arms

[Lalitha-Iyer]

I am trying out enable_typename_discriminated_unions. Thank you, @morrys and relay team for pushing this feature forward!

I found a bug. Sharing some repros. I would like to hear your thoughts on what we think the expected output should be.

Bug: When typegen handles a fragment on an abstract type that mixes abstract and concrete inline fragments, it builds incorrect discriminated union arms:

Case 1 :

Fields from an abstract spread (e.g. ... on Named { name }) are merged onto concrete arms that do not implement that abstract type (e.g. Page).

Input

fragment AbstractConcreteMixedInline on Actor {
  __typename
  id
  ... on Named { name }       # abstract type -  only User implements Named (not Page)
  ... on User { firstName }
  ... on Page { subscribeStatus }
}

Output - name incorrectly on Page

| { __typename: "Page"; id: string; name?: string; subscribeStatus: string }
| { __typename: "User"; id: string; name?: string; firstName: string }
| { __typename: "%other" }


Expected Output

{ __typename: "User"; id: string; name?: string; firstName?: string }
| { __typename: "Page"; id: string; subscribeStatus?: string } // no name
| { __typename: "%other"; id: string }

Reference [test](https://github.com/Lalitha-Iyer/relay/blob/d8acd4ccf603a27f4ab4c90f02b1a61f15f1745f/compiler/crates/relay-typegen/tests/generate_typescript/fixtures/abstract-concrete-mixed-inline.expected)

### Case 2: 
Concrete arms implied only by an abstract spread can be missing (e.g., no User arm when ... on Named is selected but ... on User is not).

Input

fragment AbstractNamedWithConcretePage on Actor {
__typename
id
... on Named { name }
... on Page { subscribeStatus }
}

Actual Output - User arm missing; name on Page

{ __typename: "Page"; id: string; name?: string; subscribeStatus: string }
{ __typename: "%other" }

Expected Output 

{ __typename: "User"; id: string; name?: string } # this can be a union eg: __typename: User | FooNamedType
| { __typename: "Page"; id: string; subscribeStatus?: string } // no name
| { __typename: "%other"; id: string }

Reference [test](https://github.com/Lalitha-Iyer/relay/blob/d8acd4ccf603a27f4ab4c90f02b1a61f15f1745f/compiler/crates/relay-typegen/tests/generate_typescript/fixtures/abstract-named-with-concrete-page.expected)

[morrys]

Thanks @Lalitha-Iyer for opening the issue and for the detailed repros.

@tyao1 @captbaritone, one additional case that may be worth considering is fragment spreads on abstract types.

For example:

fragment ActorFragment on Actor {
  __typename
  id
  ...NamedFragment
  ... on Page {
    subscribeStatus
  }
}

fragment NamedFragment on Named {
  name
}

If only User and Group implement both Actor and Named, the NamedFragment reference should only be available for those concrete types. Today it can be treated like a common selection and end up on the Page arm as well, which has the same underlying problem as the fields in the examples above.

So I think the more general issue is that selections coming from an abstract type condition, including fragment spreads, are currently treated as common fields even though they may only apply to a subset of the possible concrete runtime types.

A more precise output could potentially infer the compatible concrete types from the schema and group types that produce the same shape, for example:

{
  __typename: "User" | "Group";
  id: string;
  " $fragmentSpreads": FragmentRefs<"NamedFragment">;
}
| {
  __typename: "Page";
  id: string;
  subscribeStatus: string;
}
| {
  __typename: "%other";
}

This would also avoid creating a separate union arm for every concrete type when several of them have the same selections.

If resolving all possible concrete types is considered too expensive or produces types that are too large, falling back to the flat shape for these mixed abstract/concrete cases could still be a safer alternative.