[Search] Remove client side shard timeout

[lizozom]

Summary

Partially resolves #75321

Checklist

Remove client side shard timeout

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
• This was checked for keyboard-only and screenreader accessibility
• This renders correctly on smaller devices using a responsive layout. (You can test this in your browser
• This was checked for cross-browser compatibility

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[lizozom]

@elasticmachine merge upstream

[lizozom]

@elasticmachine merge upstream

[kibanamachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request
• Commit: 11a1639
• Pipeline Steps (look for red circles / failed steps)
• Interpreting CI Failures

Failed CI Steps

• Check Types
• Check Doc API Changes

Build metrics

page load bundle size

id	value	diff	baseline
data	1.4MB	-873.0B	1.4MB
visTypeVega	661.7KB	-70.0B	661.8KB
total		-943.0B

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[lukasolson]

Hmm... Since msearch doesn't follow the normal pattern of going through our server-side search strategies, then if it's removed here, then how do we ensure that the parameter is sent in our msearch requests? We could possibly add it in the create_proxy file and import our existing server-side getSearchParams in the new platform. Thoughts?

Also, I think we can get rid of a couple of additional parameters that are sent, including ignore_unavailable, rest_total_hits_as_int, and even ignore_throttled since they are already configured server-side. We could also move max_concurrent_shard_requests to the server, but that might be outside the scope of this PR.

[lizozom]

@lukeelmers Since msearch uses a uniquely formatted body, it seems to be impossible injecting the timeout on the server or any other parameter for the time being, without parsing and re-creating the body string.

Once we create our msearch route, we could simplify the way the data is sent to that endpoint (I would use a JSON array, with each object having a body and a header option). Then on the server we will be able to format them correctly and inject the desired parameters.

[lukeelmers]

Okay @lizozom, so it sounds like it's best to revisit after #55139 is resolved

[lizozom]

Addressed in #75943 and #75728