[Search] Cleanup SearchRequest and SearchResponse types

[lizozom]

Summary

During the NP migration, we created a couple of internal types for SearchRequest and SearchResponse, defining them to be any.

This PR

• Replaces SearchRequest, in the few places it was used, with Record<string, any> (Being the result of searchSource.flatten())
• Replaces SearchResponse with the type defined in the elasticsearch client library.

I opened a couple of issues for gaps in the Elasticsearch Client types

• Add a type for a search error response elasticsearch-js#1287
• ShardsResponse is missing a field returned from ES elasticsearch-js#1286

And for the time being used casting to any to work around those issues.

Checklist

Delete any items that are not applicable to this PR.

• 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

[elasticmachine]

Pinging @elastic/kibana-app-arch (Team:AppArch)

[lukeelmers]

The more I think about this, it might be a good idea to keep SearchRequest around since there isn't currently a replacement for it.

If we switch everything to use Record, it will make it much harder to find usages of this type later if we want to change it again. Whereas if we keep SearchRequest around and simply update the typings for it, it'll be much easier to locate in the future.

[lukasolson]

I have to agree with @lukeelmers here... I think the changes to SearchResponse make a lot of sense, but I think we should make changes directly to the TS definition for SearchRequest rather than everywhere SearchRequest is used. In the future, if we keep SearchRequest, it will be much easier to refactor once we actually have a valid type.

[lukeelmers]

Code changes LGTM. The fact that we are still stuck using any in a few places is a bummer, but this is still a worthwhile improvement to the status quo.

Hopefully if we get more detailed typings in the client in the future, we will be able to come back and tighten some of these up.

[kertal]

Code LGTM, KibanaApp CodeOwner review, checked out, tested input control and Discover context, works

[lukasolson]

Code LGTM

[lizozom]

@elasticmachine merge upstream

[elasticmachine]

merge conflict between base and head

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 86c5443

Build metrics

async chunks size

id	value	diff	baseline
discover	430.6KB	+79.0B	430.6KB

page load bundle size

id	value	diff	baseline
data	1.4MB	-278.0B	1.4MB
infra	275.6KB	+75.0B	275.6KB
total		-203.0B

History

• 💚 Build #69391 succeeded 143e297
• 💚 Build #69364 succeeded cc67228
• 💔 Build #69345 failed ae913fa
• 💚 Build #69196 succeeded 1ad1001
• 💔 Build #69170 failed e619092

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