EuiFocusTrap; dependency changes

[thompsongl]

Summary

Enables focus trapping in mixed content-in-portal flows.

• Move from focus-trap-react to react-focus-lock for focus trapping needs.
  • Our current focus trapping solution does not account for or support content projected via React portals (e.g., EuiPopover) in component subtrees. That is, focus state and tab order are lost when users encounter content in React portals during normal keyboard interaction.
  • react-focus-lock solves the above problem by default.
• Adds a new component: EuiFocusTrap
  • Set reasonable defaults for passthrough props (it wraps react-focus-lock).
  • Composes EuiOutsideClickDetector and a portal-specific React event handler to determine if clicks/keypresses happen outside the component subtree.
  • Clearer initalFocus API for giving certain elements focus on intialization

Resolves #1542, resolves #1495, resolves #1051
Gets at #995

Note: EUI's package react-datepicker still uses focus-trap-react, but maintains its own dependency.

Checklist

• This was checked in mobile
• This was checked in IE11

- [ ] This was checked in dark mode

• Any props added have proper autodocs
• Documentation examples were added
• A changelog entry exists and is marked appropriately
• This was checked for breaking changes and labeled appropriately
• Jest tests were updated or added to match the most common scenarios
• This was checked against keyboard-only and screenreader scenarios

- [ ] This required updates to Framer X components

[chandlerprall]

Confirmed locally that this PR addresses the issues mentioned in the description.

[chandlerprall]

Changes LGTM, pulled locally and verified examples in docs are working as intended (and fixes the targeted bugs)

[thompsongl]

@cchaos and @snide I'd appreciate a second look and test run if you have some time. @chandlerprall put in a thorough technical review already.

[snide]

I'll give it a pass today for functionality. I'll yarn link kibana over, @bevacqua might want to do the same with cloud.

[snide]

Tested for functionality only, not code.

Ran with this for about 30 minutes testing in components we use this in in Kibana, and then against the issues mentioned for closure.

The only weirdness I noticed was that Flyouts with the ownFocus prop didn't shift their focus over in some cases. The only reproducable one I could get was the Discover app's "open" functionality. The flyout opens, but the focus stays on the button itself, rather than the item. This doesn't happen with the previous solution. Overall a pretty minor one, and the EUI docs seem to work correctly so I don't know what's up, but I did flip between the two with yarn link and could replicate. All other usages seemed to work as expected and fixed the issues mentioned.

[thompsongl]

I'm going to take another look at flyouts. I suspect there's something extra going on with that Discover implementation, but I want to see if there's any more documentation that could be helpful.

[thompsongl]

@snide So what's happening with that Discover > Open > Flyout is the focus trap is getting immediately disabled. The outsideClickDetector is catching the Open button click event and returning focus. Best guess right now is that it has to do with the way Angular is propagating that event, although it's been a long time (luckily; thankfully) since I've really triaged Angular 1.x code.

[bevacqua]

LGTM. We could really use this in Cloud

[snide]

We're gonna leave the Kibana / angular issue for the angular side. We'll create a follow up ticket on that side of the fence. Ultimately, the focus issue with flyouts is more minor than the larger bugs this fixes around portals.