Add support for missing value fetchers.

[jtibshirani]

This PR implements value fetching for the following field types:

• text phrase and prefix subfields
• search_as_you_type, plus its subfields
• token_count, which is implemented by fetching doc values

Supporting these types helps ensure that retrieving all fields through
"fields": ["*"] doesn't fail because of unsupported value fetchers.

[elasticmachine]

Pinging @elastic/es-search (:Search/Search)

[nik9000]

Makes sense to me.

When I was prototyping grok runtime fields I had a similar problem with throwing from valueFetcher. I think maybe we should add some guidance that you should never throw from this.

I wonder if it'd make sense to have some kind of "there are no values in this field" kind of marker so that * skips them. Not a "for now" problem - this seems perfect.

[romseygeek]

I'm not sure that the implementation is correct for the text/search-as-you-type subfields? I may just be missing something though.

[jtibshirani]

I'm not sure that the implementation is correct for the text/search-as-you-type subfields? I may just be missing something though.

This current implementation indeed works (and is tested through FieldFetcherTests#testTextSubFields). Because the internal fields are modelled as multi-fields, the logic in SourceValueFetcher to resolve multi-fields in _source kicks in and we successfully retrieve the value from the parent field. It felt simplest to just treat them as multi-fields instead of adding special (and redundant) logic to look in the parent. I should really at least add a comment, at first glance it's unclear why this works!

[romseygeek]

I should really at least add a comment, at first glance it's unclear why this works!

That would be great, thanks. LGTM otherwise!

[jtibshirani]

@nik9000 your DocValueFetcher addition is coming in really handy :)

I wonder if it'd make sense to have some kind of "there are no values in this field" kind of marker so that * skips them.

I guess an alternative approach would be to return no values instead of throwing. Right now, I'd prefer to keep the approach simple and return values for all registered fields. If we don't want to return values, then I think a better option is to avoid registering internal text fields at all -- I filed #63446 to discuss this idea.