Resolve missing types "Boolean", "String"

[trevor-scheer]

Preface

A change to graphql's buildClientSchema removed some behavior that we depended on. Previously, with caching in place, basic types (Boolean, String, ...) were returned even if they didn't exist in typeMap. The "fix" was itself a breaking change, adding basic types that weren't previously added to the typeMap.

Full discussion here: graphql/graphql-js@183ff32#r32971387

Chain of events

• This commit lands in the 14.2.0 release, breaking our usage of buildClientSchema
  Remove excessive cache inside buildClientSchema graphql/graphql-js#1677
• A follow-up fix is released in 14.2.1, which is itself a breaking change
  buildClientSchema: Revert breaking change introduced in #1677 graphql/graphql-js#1808
• The breaking change is noted in the discussion above^, resulting in the release of 14.3.1 with this fix:
  buildClientSchema: include standard type only if it is used graphql/graphql-js#1809

Approach / Discussion

@justinanastos and I discovered with some digging that we depended on buildClientSchema to fill in the missing built-in types for us (we were handing off an incomplete schema, but it would correct our error). We realized that we can request the built-in types and solve the problem on our end by passing a complete schema.

This PR addresses a couple issues that stem from the ongoing graphql issue (and subsequent fixes):

1. We can request the built in types from Engine so they won't be missing to begin with
2. Disallow versions of graphql that include the broken fix [email protected] - 14.3.0.

Why exclude the range 14.2.1 - 14.3.0?

The broken fix causes a regression for service:push. Through the version range of the broken fix, ALL built in types are included during buildClientSchema (even if they're not part of the schema). This causes a hash mismatch between the pushed schema and the schema hash that Apollo Server recognizes.

Fixes #1296
Fixes #1295

TODO:

• Update CHANGELOG.md* with your change (include reference to issue & this PR)
• Make sure all of the significant new logic is covered by tests
• Rebase your changes on master so that they can be merged easily
• Make sure all tests and linter rules pass

*Make sure changelog entries note which project(s) has been affected. See older entries for examples on what this looks like.

[abernix]

LGTM!

[abernix]

Note that, as we discovered on our out-of-band call, spaces must be used in the version ranges in order to properly differentiate them from just general hyphens in version names, as I've "suggested" below.

[abernix]

Same as previous comment!