Simplify how source is passed to fetch subphases.

[jtibshirani]

This PR simplifies how the document source is passed to each fetch subphase. A summary of the strategy:

• For each document, we try to eagerly load the source and store it on HitContext. Most subphases that access source, like source filtering and highlighting, use HitContext. For nested hits, we filter the parent source and also store this source on HitContext.
• Only for non-nested documents, we also store the loaded source on QueryShardContext#lookup. This allows subphases that access source through SearchLookup to use the pre-loaded source when possible. This is now a common occurrence, since runtime fields are supported in the 'fields' option and may soon be supported in highlighting.

There is no longer a special SearchLookup just for the fetch phase. This was not necessary and was mostly caused by a misunderstanding of how QueryShardContext should be used.

Addresses #62511.

[jtibshirani]

This protects against reintroducing the bug in #31000. I should have added this test when fixing the bug originally, but better late than never!

[jtibshirani]

A question that might come up: why not go further and provide source access in only one place? Maybe we could remove HitContext#sourceLookup and just have QueryShardContext#searchLookup? Here are the downsides I see:

• A subphase could easily reposition the lookup on QueryShardContext and invalidate the document source. This can cause subtle bugs, as in _source not returned in "explain": true with certain queries #31000. (We don't yet guard against this for HitContext#lookup, but we could certainly add a check that the document ID never changes.)
• It adds complexity when handling nested documents. When processing a nested document, we would have to store the filtered source on QueryShardContext, invalidating the source for the parent document. This is maybe okay if inner_hits is always run last, but it's fragile and introduces an ordering requirement on phases.

My mental model is that HitContext provides reliable access to the preloaded source for a particular document. QueryShardContext gives more flexible lookup ability, but it's just a 'best effort' as to whether the preloaded source is available.

[elasticmachine]

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

[romseygeek]

This clashes slightly with #65219 but I think the two can be reconciled. I particularly like the simplification to MappedFieldType#valueFetcher - I wonder if that can be done as a separate change?

[jtibshirani]

This clashes slightly with #65219 but I think the two can be reconciled

My apologies, I had meant to submit this comment earlier but it didn't go through! Would you be okay reviewing this one first, as I think it will clarify the requirements (and it's actively causing difficulties with other PRs, as in #63572)?

I particularly like the simplification to MappedFieldType#valueFetcher - I wonder if that can be done as a separate change?

I think it needs to be done as part of this change. Before, the fetch phase used its own SearchLookup separate from the one on QueryShardContext.

[romseygeek]

LGTM, thanks @jtibshirani