[Lens] Faster field existence failures by adding timeouts

[wylieconlon]

We've decided that if the field existence query takes too long, we want to fail and show all fields. I've been unable to find large improvements to the performance, but there are some small improvements to the failure case added here.

One case that is hard to work with is many shards: there is a per-shard timeout and a global timeout, so I've set the per-shard timeout very low and the per-shard timeout higher.

This adds a new timeout warning to the field list:

Closes #92493

[elasticmachine]

Pinging @elastic/kibana-app (Team:KibanaApp)

[flash1293]

Tested and still works fine, LGTM.

Two notes:

• Should we extend the error message shown in the UI with the ES error message (or maybe hide it if it's because of a timeout)? Some users will always see this warning triangle because their cluster is slow. We did something similar for the input control vis and it caused quite some user confusion (Input controls: Improve behavior on terms list timeout #73253)
• 500ms to 5s seems like a pretty big difference - could you explain how you arrived at these values? I'm no expert, but I would have expected the shard timeout to be much higher.

[wylieconlon]

@flash1293 I will look at options to show a better explanation/icon for timeouts vs other types of failures. Maybe a clock icon instead of a warning triangle would be appropriate.

I can clarify this using a comment in the issue, but you're right that we could move the timeouts closer together, for example we could do 4s and 5s. One of the interesting things about a super-short timeout is that each shard will return partial results if it's found any in the time, which is kind of similar to the sampling ideas we've talked about. But if ES is bottlenecked for some reason it's probably best to have a slower timeout.

[wylieconlon]

@flash1293 please take another look as I've hooked up a new key in the state. I tested locally by setting the timeout super low.

[mbondyra]

@elasticmachine merge upstream

[flash1293]

I love this way of indicating timeouts - it's clear what's happening and users will know what to expect.

Just one thing I would like to change - as soon as you run into the timeout, field information popovers also won't be populated. This doesn't seem necessary, IMHO we should still try to run these requests even if the existence query timed out.

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: c0c07c2
• Storybooks Preview

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
lens	943.8KB	944.8KB	+1.0KB

History

• 💚 Build #120447 succeeded 2cb4685
• 💚 Build #120157 succeeded 4140971
• 💔 Build #120126 failed bdeefac
• 💔 Build #120096 failed 396d2a0
• 💚 Build #119789 succeeded 40700c3

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

[kibanamachine]

💚 Backport successful

Status	Branch	Result
✅	7.x

This backport PR will be merged automatically after passing CI.