This is an alternative solution to #776 wherein __typename is explicitly allowed inspired by @IvanGoncharov's comment on that PR.

Description of issue

__typename does not return an event stream, so it does not make sense to allow for it to be the source stream in a GraphQL subscription operation. As currently specified, the following query passes validation, but it should always produce an error since the ResolveFieldEventStream algorithm cannot resolve a subscription resolver for __typename:

subscription {
  __typename
}

Separately; it's valid to add __typename to any selection set in any GraphQL operation except the root selection set (including fragments) on a Subscription operation. This exclusion complicates life for various GraphQL tooling; it's desirable that this (currently invalid) GraphQL operation be valid:

subscription sub {
  newMessage {
    body
    sender
  }
  __typename
}

The current GraphQL algorithm for subscriptions operates in two steps; first it resolves the "source stream" from the root field that will generate the subscription events, and then when an event is received it executes the entire operation (NOTE: not just the selection set of the source stream's field, but the entire selection set of the operation) using this event as the initialValue. As such, __typename could be valid in the root selection set so long as there is exactly one field capable of providing the source stream.

Solution outline

• Change validation for subscription operations so that instead of saying the root selection set must include exactly one field, it's now exactly one non-introspection field.
• Change CreateSourceEventStream such that it uses this non-introspection field as the event source (i.e. so that it ignores introspection fields).