Preserve highlighting for returnable: false fields

[jwils]

Summary

• rebased onto the updated joshauw/returnable-widgets-schema parent branch
• preserve highlighting for returnable: false fields by only excluding non-highlightable hidden fields from _source
• add unit coverage for the refined _source.excludes behavior
• add acceptance coverage proving hidden widget fields can still be filtered, sorted/grouped/aggregated, highlighted, and rejected from direct selection

Testing

• re-verified after rebasing: bundle exec rspec elasticgraph-schema_definition/spec/unit/elastic_graph/schema_definition/datastore_config/index_mappings/miscellaneous_spec.rb
• bundle exec rspec elasticgraph-schema_definition/spec/unit/elastic_graph/schema_definition/datastore_config/index_mappings/miscellaneous_spec.rb
• NO_VCR=1 bundle exec rspec elasticgraph-graphql/spec/acceptance/returnable_fields_spec.rb
• script/lint elasticgraph-schema_definition/lib/elastic_graph/schema_definition/mixins/has_indices.rb elasticgraph-schema_definition/spec/unit/elastic_graph/schema_definition/datastore_config/index_mappings/miscellaneous_spec.rb elasticgraph-graphql/spec/acceptance/returnable_fields_spec.rb

[myronmarston]

Good catch--I hadn't considered how highlightable interacts here. I agree that a returnable: false, highlightable: true field should behave as you've demonstrated here. However, I think it's reasonable for field.highlightable? to return false for a returnable: false field. That is: if the caller hasn't passed highlightable: ... at all, I think returnable: false should make the field non-highlightable.

After all, the primary reason to pass returnable: false is to achieve storage savings, and it would be a bit silly/frustrating for a user to pass returnable: false (without knowing they also need to pass highlightable: false) and have it not provide any storage savings. And the various -able? predicates on Field are meant to provide intelligent defaulting. sortable?, groupable?, aggregatable?, and highlightable? all have intelligent defaulting logic. highlightable? can also have additional logic.

BTW, it feels like #1108 is incomplete without the schema def updates you've added here--so, if it's easy to do, consider moving the schema def updates from this PR to that one, the artifact updates from this to #1119, and then this can just be the acceptance test. (But it's also ok in the form you have it.)

[myronmarston]

What if field isn't highlightable but one or more of its subfields are highlightable? I'm not quite sure what the behavior should be in that case, but we should consider it. (And tests should cover it).

Edit: we should probably look at how the other -able? fields behave when they return false for a parent field and true for a child field--we'd want consistency with how that's treated.

[myronmarston]

I often like keyword arguments (particularly to avoid issues related to passing args in the wrong order) but since the only caller of this method which passes args is a recursive call from within the method...it's easy to see the method signature above. So in this case I think I'd prefer to make these positional args and collapse it to one line:

Suggested change

	object_type.source_excludes_paths(
	path_prefix: "#{path}.",
	under_non_returnable_parent: non_returnable
	)
	object_type.source_excludes_paths("#{path}.", non_returnable)