Add GraphQL::Execution::Lookahead#selections

[ianks]

This PR adds the ability to get all of the selections from a Lookahead. I decided to keep the implementation simple by just re-using the selection method instead of refactoring, let me know if that's alright 😄

Continuation of #1894

[rmosolgo]

👏 ! Thanks for taking this on! I added a couple comments about how it could be made more consistent, let me know what you think.

[ianks]

@rmosolgo addressed your comments, should be good now once CI passes. Thanks for the help!

[rmosolgo]

Cool, thanks for taking a look! What do you think of my suggestion in 8bb135c ? Effectively, it merges selections, so that

a { b } 
a { c } 

Is treated the same as

a { b c } 

The GraphQL runtime does this, too -- a is only executed once. This causes selections.map(&:name) to return only [:a], not [:a, :a], does that seem ok to you?

[ianks]

Ahhh ok. What is the reasoning for only returning it once? I would think that they are different selections because they have different sub-selections, This could potentially cause issues when attempting to dig deeped into the sub-lookaheads.

ie.

query_ one = a { b } 
query_two  = a { c } 

query_one.selections.find('a').selections # => ['b']
query_one.selections.find('a').selections # => ['c']

[rmosolgo]

cause issues

I'm sorry, I don't quite see it. Could you help me understand what scenario you want the different AST nodes reflected in a lookahead? Like, when would you interact with a lookahead that you want to distinguish between these two GraphQL snippets:

# snippet 1, the client has requested data in two different selections, 
# even though they're merged during query execution 
query {
  users { totalCount } 
  users { name } 
end 

# Snippet 2, `totalCount` and `name` are part of the same selection
query {
  users { 
    totalCount 
    name 
  }
}

What I've done in 8bb135c is normalized in that case, so regardless of whether the client sends snippet 1 or snippet 2, it looks the same:

users_field = lookahead.selection("users")
p users_field.selections.map(&:name)
# [:total_count, :name]

☝️ consider that bit of Ruby code, perhaps inside a resolver. If lookahead didn't merge subselections, what output would you expect for that Ruby code in the case of GraphQL snippet 1 and GraphQL snippet 2 above?

[ianks]

This makes sense now, and is a much better way of dealing with the problem. Essentially, we can consider 'name' to be unique?

[rmosolgo]

👌 Bingo! .selections will never return two lookaheads with the same name.

Ok, caveat: there are still unhandled edge cases here with aliases. For example, I'm not really sure what this will return:

query {
  users { 
    totalCount 
    name 
    alsoName: name 
  }
}

Because Lookahead pays no mind to alias. Honestly, I'm not to worried about it, because it works ok for my own case. It suits me to cross that bridge when we get to it!