Update GraphQL a little bit

[evansiroky]

Take some very minor and reasonable changes that were included in #144 and call it good with updating graphQL a bit.

• Update GraphQL library from v4.2 to v11.0
• Add limit argument to routes nestedJdbcFetcher of stops
• Rename a few variables in JdbcFetcher so the query building makes more sense
• Add tests for highly nested GraphQL queries

[codecov-io]

Codecov Report

Merging #149 into dev will increase coverage by 0.01%.
The diff coverage is 68.42%.

@@             Coverage Diff              @@
##                dev     #149      +/-   ##
============================================
+ Coverage     55.17%   55.18%   +0.01%     
  Complexity      731      731              
============================================
  Files           143      143              
  Lines          7176     7181       +5     
  Branches        830      830              
============================================
+ Hits           3959     3963       +4     
- Misses         2880     2881       +1     
  Partials        337      337

Impacted Files	Coverage Δ	Complexity Δ
...om/conveyal/gtfs/graphql/fetchers/FeedFetcher.java	79.16% <100%> (+0.9%)	4 <0> (ø)	⬇️
...in/java/com/conveyal/gtfs/graphql/GraphQLUtil.java	96.29% <100%> (ø)	6 <0> (ø)	⬇️
...a/com/conveyal/gtfs/graphql/GraphQLGtfsSchema.java	98.25% <100%> (ø)	1 <0> (ø)	⬇️
...onveyal/gtfs/graphql/fetchers/RowCountFetcher.java	67.77% <50%> (-0.41%)	11 <0> (ø)
...om/conveyal/gtfs/graphql/fetchers/JDBCFetcher.java	56.83% <67.85%> (+0.23%)	25 <14> (ø)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1a3de7d...88b269e. Read the comment docs.

[landonreed]

Looks good to me. Only major comment is do we need or want to keep the superNested.txt test? If I remember correctly, we seemed to think that it was testing queries that we wouldn't expect to see in the wild.

[abyrd]

My sense is that the super-nested query could be good for ensuring that the mechanism works properly - if it's a test of stability and functionality then it makes sense. I don't think it should be timed or have its performance otherwise measured though, as that could lead us to make compromises or time investments in development that do not improve our actual use cases.

As said in a comment on #144, the contrived query is still great as a unit test case, for verification of the results against expected output to ensure that the code does what it's intended to do.

[landonreed]

🎉 This PR is included in version 4.1.2 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀