Further improve infer fields recursion

[jasonphillips]

Okay: following upon the last PR (#2436), which successfully fixed the main error I was running into with adding fields containing circularity, I have by necessity been pushing this functionality through a much more rigorous use case, with a relatively large custom schema I am attaching to an object type in a current project.

As a result, I found two further errors downstream during conversion of large nested types, each of which has been added to the tests and then addressed in this PR:

• after the PR, nested lists still weren't always protected for circularity correctly -- because, while @Zalastax echoed my thinking that type.name is always distinct, it turns out that the type.name key isn't always set yet at that point for hybrid (wrapped) types like GraphQLList(OtherType). So, I went ahead and adopted the helpful prior suggestion of using Set() since it was cleared for compatibility in the discussion.

• the next error occurred when circularity protection ended up leaving a GraphQLObjectType with no child fields, when all were ignored due to circularity. I now test for types to have at least one accepted field before creation.

• finally, I ran into one further apparent omission, which is the handling of the GraphQLID type. It is a scalar and an instance of GraphQLScalarType, but fell into the cracks on the list of types supported for filters, which led to an error if I switched the current recursion unit test to contain GraphQLID rather than GraphQLInt types at the deepest point. This type is now handled like the other scalars.

After fixing all of those, my large, nested schema attaches without error via a plugin, and given the size of that schema, it should represent a near-comprehensive test of this functionality.

However, in a future PR, I'm very interested in pursuing an alternate API hook to setFieldsOnGraphQLNodeType (analogous to the existence of the -Statefully alternative for createPages). The use case is that there can be a great benefit to adding custom graphql sub-schemas into gatsby's schema via plugins, and some of those (like my current project) are built for querying an API outside of gatsby using various methods, particularly where that other API is far too large to simply import all nodes and let gatsby handle resolution, yet where there is still much to gain from allowing the data to be queried and pre-bundled at the page level with all the other graphql data. For these cases, it is generally not necessary for gatsby to automatically create a ton of filters to use down that long subtree, when those filters are often going to be unusable for these external APIs anyway. If there are thoughts on that alternative API hook or its naming, I'd be interested in putting it together.

[KyleAMathews]

Deploy preview failed.

Built with commit 3e96d49

https://app.netlify.com/sites/using-glamor/deploys/59e11607a6188f5554f4c259

[gatsbybot]

Deploy preview ready!

Built with commit 3e96d49

https://deploy-preview-2452--gatsbygram.netlify.com

[KyleAMathews]

Awesome! Love these PRs as you're expanding Gatsby's functionality in a really interesting area.

To your question — basically you want to be able to add standalone GraphQL types. I can definitely see the value to this. There's plenty of REST APIs where the data available is too large to simply sync it over and infer a schema.

Also, on a tangent but related. From conversations I've been having with companies with existing GraphQL schemas, Gatsby needs a way to "mirror" existing external GraphQL schemas. The recent work Apollo has been doing with schema stitching seems perfect for this https://dev-blog.apollodata.com/graphql-schema-stitching-8af23354ac37