[Lens] prompt user when editor performance is impacted

[drewdaemon]

Describe the feature:
We implemented the ability to hide Lens suggestions and disable auto-apply in order to improve editor performance.

Both of these can significantly improve the situation, but disabling auto-apply is hidden in our settings menu and hiding the suggestions may not be an obvious action to the user (e.g. they may not understand that the suggestions are contributing to the slow experience).

Can we detect bad performance and prompt the user with these options?

Some context on the problem

Source of bad performances have been identified so far in the following areas:

1. Suggestions
2. suggestion requests might take a long time to complete and the editor will still hang up until the last suggestion has completed to render
3. rendering can be slow in some very specific conditions (mostly super high cardinality bucketing + breakdowns).
4. Dimension editing
5. Some dimension controls are not correctly debounced and might add up to other changes providing a degradated experience to the user.

So far the suggestion request has been the major problem here, leading to several changes in the past who improved the local situation, but still targeting specific workarounds rather than the general problem:

• Make the Suggestion panel toggleable as workaround
• Avoid to propose a Over time suggestion if an high cardinality Top values dimension is detected
• Make the "auto-apply" behaviour configurable

Attacking the general problem

Some ideas have been brought to the table in some discussion to tackle the general problem and here's a summary of them:

• Use some sampling strategy to reduce the request time for suggestions
  • [Lens] Support Sampler & Diversified Sampler aggregations #120788 - while this specific issue require us to implement the support for these two agg types in Lens, there's today the option to leverage also the random sampler for suggestions which is already implemented.
  • an alternative approach would be to reuse - where possible - the current dataset with a client-side down-sampling approach.
• Reduce the configuration to smaller cardinality where possible
  • Similar idea to the sampling one, but this one works on the bucketing cardinality in case of high buckets/breakdown by dimensions
• Bail out of slow suggestions
  • [Lens] Bail out of suggestion rendering if load times are too long #100345 - while this issue sets a target timeout of 30s, this can be reduced as well
  • [Lens] Render suggestions after main chart #100346 - or alternatively render the suggestions only after the main workspace has rendered (not clear here the real benefits of the delay)

[elasticmachine]

Pinging @elastic/kibana-visualizations @elastic/kibana-visualizations-external (Team:Visualizations)

[drewdaemon]

From our discussion, these slowdowns can be caused by either network-bound or CPU-bound processes.

Network requests are async, so network-bound slowdowns could theoretically be detected and remediated (notification to user, cancellation of the request, etc) before the response is received.

Rendering (CPU-bound) is currently synchronous so detecting and applying performance remediation strategies mid-render is difficult (impossible as things currently stand?). However, it occurs to me that the detection can always be applied after a long render has been completed as well.

Sure, it would be better if we could do it before render completion, but detecting a performance degradation is a win no matter what IMO.