Resolve elasticgraph-apollo confusing rake warnings

[ayousufi]

Problem
#690

Solution
This change updates the schema validation logic to ignore Apollo's internal resolvers the same way core ElasticGraph resolvers are handled.

How Tested
Added a unit test to ensure that warnings are not emitted by registered Apollo-prefixed resolvers when they are unused.

[myronmarston]

I think there's a more robust way to test this:

diff --git a/elasticgraph-apollo/spec/unit/elastic_graph/apollo/schema_definition_spec.rb b/elasticgraph-apollo/spec/unit/elastic_graph/apollo/schema_definition_spec.rb
index 865f52da..8654b340 100644
--- a/elasticgraph-apollo/spec/unit/elastic_graph/apollo/schema_definition_spec.rb
+++ b/elasticgraph-apollo/spec/unit/elastic_graph/apollo/schema_definition_spec.rb
@@ -13,11 +13,16 @@ require "graphql"
 
 module ElasticGraph
   module Apollo
-    RSpec.describe SchemaDefinition do
+    RSpec.describe SchemaDefinition, :capture_logs do
       include SchemaArtifacts::RuntimeMetadata::RuntimeMetadataSupport
 
       include_context "SchemaDefinitionHelpers"
 
+      after do
+        # No warning messages should be logged.
+        expect(logged_output).to exclude(/warn/i)
+      end
+
       def self.with_both_casing_forms(&block)
         context "with schema elements configured to use camelCase" do
           let(:schema_element_name_form) { :camelCase }

Essentially, test that no messages containing "warn" are logged by any of our Apollo schema definition specs. This is more robust because:

• It handles all warnings, not just this specific one. For example, if a future change to elasticgraph-schema_definition causes new warnings to be logged from elasticgraph-apollo, it'll catch it.
• It applies the assertion to every elasticgraph-apollo schema definition spec so that it covers a wide variety of cases, not just one specific case.
• It's less coupled to the current implementation. This spec, residing in elasticgraph-schema_definition, simulates what elasticgraph-apollo does but overtime that could shift. If our goal is to ensure that elasticgraph-apollo doesn't produce warnings, it's more robust to verify that it doesn't produce warnings, rather than having a spec here that simulates how elasticgraph-apollo is currently implemented, and asserting that it doesn't produce a warning.

[myronmarston]

I was OK with checking elastic_graph/graphql/resolvers/ because those paths are already present in this gem:

elasticgraph/elasticgraph-schema_definition/lib/elastic_graph/schema_definition/schema_elements/built_in_types.rb

Lines 1424 to 1447 in 2f6afe0

	def register_standard_graphql_resolvers
	require(require_path = "elastic_graph/graphql/resolvers/get_record_field_value")
	schema_def_api.register_graphql_resolver :get_record_field_value,
	GraphQL::Resolvers::GetRecordFieldValue,
	defined_at: require_path
	require(require_path = "elastic_graph/graphql/resolvers/list_records")
	schema_def_api.register_graphql_resolver :list_records,
	GraphQL::Resolvers::ListRecords,
	defined_at: require_path
	require(require_path = "elastic_graph/graphql/resolvers/nested_relationships")
	schema_def_api.register_graphql_resolver :nested_relationships,
	GraphQL::Resolvers::NestedRelationships,
	defined_at: require_path
	require(require_path = "elastic_graph/graphql/resolvers/object")
	schema_def_api.register_graphql_resolver :object_with_lookahead,
	GraphQL::Resolvers::Object::WithLookahead,
	defined_at: require_path
	schema_def_api.register_graphql_resolver :object_without_lookahead,
	GraphQL::Resolvers::Object::WithoutLookahead,
	defined_at: require_path
	end

Since those resolvers are registered within this gem, it felt reasonable to special case them here. But it doesn't feel right to do the same for elasticgraph-apollo--it's a separate gem, and elasticgraph-schema_definition is intended to have no knowledge of its existence. Concretely, it also means that there's no way for another extension library that's similar to elasticgraph-apollo, but defined outside of this codebase, to register resolvers while avoiding the warning.

Here's an alternate idea: let's add the concept of built_in? to our GraphQL resolvers. When registering a resolver, we can pass built_in: true, and the logic here can filter out all built-in resolvers. It's appropriate for a built-in resolver to be unused and there's no reason to warn about it. We can pass built_in: true when registering our elasticgraph-graphql resolvers and also our elasticgraph-apollo resolvers--and any other gem could do the same. Also, we could improve the unused resolver warning to mention the option of passing built_in: true.

Thoughts?