…ts (#142875)

Change from partial_results to return_intermediate_results

#141073 introduced a new query parameter to allow clients to decide whether or not intermediate results should be returned when getting async search results if the query is not complete. The initial Github issue asked for a partial_results query parameter but it was decided to change it to return_intermediate_results. That change was made in the PR in all places except for RestGetAsyncSearchAction. This PR corrects that oversight.

…ts (elastic#142875)

Change from partial_results to return_intermediate_results

elastic#141073 introduced a new query parameter to allow clients to decide whether or not intermediate results should be returned when getting async search results if the query is not complete. The initial Github issue asked for a partial_results query parameter but it was decided to change it to return_intermediate_results. That change was made in the PR in all places except for RestGetAsyncSearchAction. This PR corrects that oversight.

…ts (elastic#142875)

Change from partial_results to return_intermediate_results

elastic#141073 introduced a new query parameter to allow clients to decide whether or not intermediate results should be returned when getting async search results if the query is not complete. The initial Github issue asked for a partial_results query parameter but it was decided to change it to return_intermediate_results. That change was made in the PR in all places except for RestGetAsyncSearchAction. This PR corrects that oversight.

## Summary

Close #229903
Close #186145

This PR implements two key (async) search performance optimizations
related to polling.
1. When the browser is using a protocol which supports multiplexing,
Kibana-side sleeps are eliminated and long-polling is used, ensuring
results are delivered as soon as possible.
2. One of the Elasticsearch requests that used to happen after polling
has been removed.

## Reviewer notes

`retrieveResults` has been renamed to `returnIntermediateResults` to
match the Elasticsearch [parameter
name](elastic/elasticsearch#141073), but should
be functionally identical.

## Settings behavior

### `wait_for_completion_timeout`

```mermaid
  flowchart TD
      Start[Start] --> Phase{Phase?}

      Phase -->|Initial Submit| SubmitConfig[Use search.asyncSearch.waitForCompletion]

      Phase -->|Polling GET| ClientConfig{search.asyncSearch.pollLength set?}

      ClientConfig -->|Yes - Number| UseClientConfig[Use config value]
      ClientConfig -->|No| Multiplex{Is the browser using HTTP/2 or<br/>HTTP/3?}

      Multiplex -->|Yes| Use30s[Use 30000ms]
      Multiplex -->|No| Undefined[Omitted - functionally zero]
```

### `pollInterval`

```mermaid
  flowchart TD
      Start[Start] --> ConfigSet{search.asyncSearch.pollInterval set?}

      ConfigSet -->|Yes| UseConfig[Use config value]
      ConfigSet -->|No| CheckMultiplex{HTTP/2 or<br/>HTTP/3?}

      CheckMultiplex -->|Yes| UseZero[Use 0ms]
      CheckMultiplex -->|No| CheckStatic{Static value<br/>provided?}

      CheckStatic -->|Yes| UseStatic[Use that value]
      CheckStatic -->|No| ElapsedTime{Elapsed time?}

      ElapsedTime -->|< 1.5s| Use300[300ms]
      ElapsedTime -->|< 5s| Use1000[1000ms]
      ElapsedTime -->|< 20s| Use2500[2500ms]
      ElapsedTime -->|>= 20s| Use5000[5000ms]
```

### Checklist

- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)

### Identify risks

The main risk is if an on-prem deployment has for some reason configured
aggressive network timeouts and also has HTTP/2 enabled for browser
communication, they may see timeout errors after upgrading.

- has set `elasticsearch.idleSocketTimeout` or `server.socketTimeout` to
a value less than 30 seconds.
- uses a proxy that has a timeout configured at less than 30 seconds.

In all these cases, the user can fix the behavior by raising the
interfering timeouts (preferred) or by tuning down the poll length via
`kibana.yml`.

### Release note

Sped up fetching Elasticsearch data for setups using HTTP/2 as the
browser's communication protocol.

---------

Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Stratou <efstratia.kalafateli@elastic.co>