Summary

This is PR 1/2 to convert EuiKeyPadMenu to Emotion. This PR takes care of converting EuiKeyPadMenu and a PR will come later to convert EuiKeyPadMenuItem.

Note: EuiKeyPadMenu variables were not removed as they are still being used by EuiKeyPadMenuItem.

QA

Remove or strikethrough items that do not apply to your PR.

General checklist

• Checked in both light and dark modes
• Checked in mobile
• Checked in Chrome, Safari, Edge, and Firefox
• Checked for breaking changes and labeled appropriately
• Checked for accessibility including keyboard-only and screenreader modes
• A changelog entry exists and is marked appropriately

Emotion conversion checklist

• Does it work?
• Output CSS matches the previous CSS / as expected in browsers
• Rendered className reads as expected in snapshots and in browsers
  - [ ] Checked component playground (class components wrapped in withEuiTheme need to pass true as the second argument to its propUtilityForPlayground in src-docs/src/views/{component}/playground.js)
   
• Unit tests
• shouldRenderCustomStyles() test was added and passes with parent component and any nested childProps (e.g. tooltipProps)
  - [ ] Removed any mount()ed snapshots in favor of render() or a more specific assertion
   
• Sass/Emotion conversion process
• Converted all global Sass vars/mixins to JS (e.g. $euiSize to euiTheme.size.base) No: `EuiKeyPadMenuItem still needs them
• Removed or converted component-specific Sass vars/mixins to exported JS versions, listed removals in changelog, and manually updated our theme JSON files
• Simplified calc() to mathWithUnits if possible (if mixing different unit types, this may not be possible)
  - [ ] Added an @warn deprecation message within the global_styling/mixins/{component}.scss file
• Removed component from src/components/index.scss
  - [ ] Deleted any src/amsterdam/overrides/{component}.scss files (styles within should have been converted to the baseline Emotion styles)
   
• CSS tech debt
• Reduced specificity where possible (usually by reducing nesting and class name chaining)
  - [ ] Wrapped all animations or transitions in euiCanAnimate
• Used gap property to add margin between items if using flex
• Converted side specific padding, margin, and position to -inline and -block logical properties (check inline styles as well as CSS)
   
• DOM cleanup
• Did not remove any block/element classNames (e.g. euiComponent, euiComponent__child)
  - [ ] Deleted any modifier classNames or maps if not being used in Kibana. Before doing this step:
   
• Kibana due diligence
• Pre-emptively check how your conversion will impact the next Kibana upgrade. This entails searching/grepping through Kibana (excluding **/target, **/*.snap, **/*.storyshot for less noise) for eui{Component} (case sensitive) to find:
  Checked in Kibana and the snapshots / style updates are for EuiKeyPadMenuItem, not EuiKeyPadMenu
• Any test/query selectors that will need to be updated
• Any Sass or CSS that will need to be updated, particularly if a component Sass var was deleted
• Any direct className usages that will need to be refactored (e.g. someone calling the euiBadge class on a div instead of simply using the EuiBadge component)
   
• Extras/nice-to-have
  - [ ] Documentation pass:
  - [ ] Converted any remaining .js docs files to TS
  - [ ] Misc cleanup of docs code (e.g. combine imports to single from '../src', replace <React.Fragment> with <>)
  - [ ] Check for issues in the backlog that could be a quick fix for that component
  - [ ] Optional component/code cleanup: consider splitting up the component into multiple children if it's overly verbose or difficult to reason about