[Controls] Migrate range slider to EuiDualRange and make styling consistent across all controls

[Heenawter]

Closes #140135
Closes #159724

Summary

Changes to range slider

This PR migrates the range slider control to use the EuiDualRange component, which both (a) removes a bunch of range slider code , thus improving DX, and (b) improves the usability of the control by simplifying the different states and making the slide animation much smoother:

Before	After

Note that, due to the fact that migrating to the EuiDualRange component means we no longer control the opening/closing of the popover, this makes the "selections that extend beyond the current min/max of the data" scenario slightly more difficult to handle. Specifically, we need to decide the best time to recalculate the min/max of the slider as the user's selections change.

The benefit of having control over the popover opening and closing was that we could calculate the range slider's min/max values when the popover opened and lock them in place so that they stayed static as the user dragged:

However, because the EuiDualRange handles the behaviour of the popover and we therefore do not know when it opens/closes, it is not currently possible to fully replicate this old behaviour. We have two main options:

1. Recalculate the min/max of the range slider the user drags, which gives a "sliding" effect:

   

2. Debounce this min/max calculation - with this, we avoid the "sliding" effect shown above, and the min/max values only get adjusted when the pin has been static for a long enough period of time (specifically, 750ms) or when the pin is dropped (i.e. the user lets go of the mouse):

   

Ultimately, I went with option 2 in this PR. As a future enhancement, we could replicate the old behaviour by adding some sort of onPopoverClosed or onPopoverOpened logic to the EuiDualRange component - however, this would need discussion with the EUI team to ensure that this is the best way to handle it and not too specific to our use case. Since EUI changes take awhile to propagate to KIbana, it's not worth holding up this PR even further.

Consistency with other control types

To keep things consistent, this PR also switches both the options list and time slider controls to use the EuiInputPopover component and removes the redundant control titles from the popover header:

Before	After

Checklist

• Unit or functional tests were updated or added to match the most common scenarios
• Any UI touched in this PR is usable by keyboard only (learn more about keyboard accessibility)
• Any UI touched in this PR does not create any new axe failures (run axe in browser: FF, Chrome)
  • Technically, it does - but this will be resolved by the @elastic/eui-team team adding an aria-label to the thumb divs ([EuiDualRangeSliders] Slider handles need accessible labels in popovers and two-handle sliders eui#7035). This is purely for the sake of axe and/or automated a11y testing - it does not actually impact a11y of the range slider, because the components missing an aria-label are never accessible via the keyboard.
• 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

[Heenawter]

WRT the "Security Solution Cypress tests, burning changed specs" failures... I'm investigating, and it seems like both of the alerts get acknowledged before the options list has time to check the counts in the "Alert list is updated when the alerts are updated" test:

Whereas, when running it locally (where it passes reliably), there is one "Open" alert and one "Acknowledged" alert, like so:

Ideally, when the test first loads, both alerts should be Open - then, the markAcknowledgedFirstAlert() will get it into the expected state. But something seems to be happening where both alerts get acknowledged before the options list has time to verify its values.

So, this doesn't seem like this is actually a problem with the options list, and is instead something funky going on with the test itself... 🤔 Also, the second attempt doesn't seem to get reset properly, so you just end up in a no data state - i.e. it always fails on the retry, which isn't ideal.

[andreadelrio]

@Heenawter seems like the fix on the EUI side came much sooner than we expected. Should we hold this off til that is released into Kibana? It shouldn't take too long.

[logeekal]

@Heenawter

since it is holiday is germany, for now, I have disabled the problematic tests and raised a bug for it : #163920

Now, all suites are passing and security tests should not block you.

[Heenawter]

@andreadelrio While that PR does improve the options list ever so slightly (it will basically function the same as it does now in this PR, but (a) the code will be a bit cleaner, because we'll no longer need the resize observer and (b) we could have a default downLeft positioning rather than the current center positioning), it still does not address the issue with the range slider being quite cramped in our small size. I brought this up with the EUI team, and they said that this is something they can add to the EuiDualRange - but we will have to wait until that PR also gets merged (plus the corresponding EUI update).

I personally think it is still best to merge this PR as-is and wait until we can fix both the options list and the range slider in the follow up :)

[andreadelrio]

Design changes LGTM. Thanks a lot!

[MadameSheema]

LGTM!!

[logeekal]

@Heenawter ,

A heads up regarding failing Serverless Security Cypress Tests. This PR will get rid of these errors as soon as it is merged. 🤞

[codearos]

Looks good! Thanks!

[kibana-ci]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: f50cc5c

Failed CI Steps

• Serverless Security Investigations Cypress Tests #4
• Security Solution Cypress Tests #3
• Security Solution Cypress Tests #9

Test Failures

• [job] [logs] Security Solution Cypress Tests #3 / Exceptions viewer read only "before each" hook for "Cannot take actions on exception" "before each" hook for "Cannot take actions on exception"

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
controls	160	156	-4

Async chunks

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

id	before	after	diff
controls	197.2KB	195.0KB	-2.2KB
securitySolution	15.7MB	15.7MB	+342.0B
total			-1.9KB

History

• 💔 Build #150884 failed 39a43e5
• 💔 Build #150685 failed c742433
• 💔 Build #150650 failed e3cbbdc
• 💚 Build #150479 succeeded a45f725
• 💔 Build #150437 failed c34b736

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

cc @Heenawter