Expand fetch phase profiling to support inner hits and top hits aggregation phases

[andrevandeven]

Is your feature request related to a problem? Please describe

This issue is part of a larger meta issue to add fetch phase information to the search profile.

I am currently implementing fetch phase profiling: Add Fetch Phase to Search Profile #18664 .

There are 3 types of fetch phases that are important to account for in profiling:

• Standard fetch phase: This is the fundamental second stage of every standard search query. It's a broad operation that retrieves the full source document (_source) for the top-ranking documents identified in the initial query phase.
• Inner Hits Fetch: This is a specialized type of fetch used to pinpoint exactly why a document with nested or parent-child data matched your query. It retrieves the specific nested objects that caused the match, not just the top-level document.
• Top Hits Aggregation (Fetch Top Hits): This is not a phase of the search itself, but rather a powerful aggregation. It allows you to fetch the top-matching documents per group or per bucket after a primary aggregation has run.

For the first stage of implementation, the fetch phase profile will only support profiling the standard fetch phase.

Describe the solution you'd like

The first step is to decide where the information from inner hits fetch and top hits aggregation fetch should be located within the profile tree. The two options are as follows:

• Nested: Nest the inner hits fetch profile under the profile breakdown of the inner hits fetch subphase that calls it (this inner hits subphase is nested under the standard fetch phase). Nest the fetch top hits phase under the profile of the top hits aggregation that calls it.
• Non-nested: All fetch phases that are profiled are listed one after the other at the root of the profile result with a label and description that classify the fetch phase (standard vs inner hits vs fetch top hits).

Related component

Search:Query Insights

Describe alternatives you've considered

No response

Additional context

No response

[bowenlan-amzn]

I prefer the non-nested approach. Although the profile structure itself won't tell inner hits phase belong to fetch phase, or top hits agg belong to query phase. But we can always document it well and that's normally a better way to transfer information.

Relying on an already huge JSON to inform user the blonging relationship feels not gonna be a good experience anyway.