Add mergeExtensions and toFullSchemaGQLDocument

[martinbonnin]

• GQLDocument.mergeExtensions() to merge extensions without doing schema validation (closes apollo-ast: support merging definitions without validation #4920)
• GQLDocument.toFullSchemaGQLDocument() to generate a verbose GQL document that merges the extensions and also contains the current builtin types as supported by Apollo Kotlin (see also Add Appendix C - Type System Definitions graphql/graphql-spec#1037)
• Hide most of the introspection classes from the public API (see 🧹 4.0 cleanups #4171)

This pull request unfortunately contains a bunch of both binary and source breaking changes. Since apollo-ast was not advertised as much as apollo-api and apollo-runtime, I'm hoping this is OK. I took this opportunity to tweak a bit the public API:

• okio is not part of stable the public API anymore (it still is experimentally available though)
• It's not possible to go from String/File to Schema directly anymore, you have to go through GQLDocument:

// Before
Buffer().writeUtf8("type Query { foo: Int }").toSchema()

// After
"type Query { foo: Int }".toGQLDocument().toSchema()

More comments inline

[netlify]

✅ Deploy Preview for apollo-android-docs canceled.

Name	Link
🔨 Latest commit	a7f442f
🔍 Latest deploy log	https://app.netlify.com/sites/apollo-android-docs/deploys/64ddef3ae68bfd00088a88af

[BoD]

👍

[martinbonnin]

I reshuffled the introspection bits again into 2 pieces:

• introspection_reader.kt contains a lenient model of introspection and tries to make a best effort guess when some fields are absent. When recoverable (description missing, directive defintions missing, etc...) a log is printed. When unrecoverable (field definitions, arguments, enumValues, etc...) an error is thrown
• introspection_writer.kt contains a strict model of the current introspection schema we support.

It's a bit verbose but that duplication makes it easier to handle the edge cases of different servers having different version of introspection

[BoD]

👍

[BoD]

Could we handle this case by passing isDeprecated + deprecationReason?

[martinbonnin]

The whole IR is based on the premise that isDeprecated = true implies deprecationReason != null. Kotlin @Deprecated annotation also requires a message. I'm still unclear what the use case is for @deprecated(reason: null). I'll add a comment there