[Vis: Default editor] EUIficate Percentile Ranks and Percentiles

[maryia-lapata]

Summary

EUIfication of Percentile Ranks and Percentiles controls for aggregation parameter in Default Editor, Data tab.
Part of #30922.

The old Percentile Ranks and Percentiles controls used number-list directive, so the directive was EUIficated to NumberList component as well.

Steps to reproduce: Create Area visualization, expand Metrics group, choose Percentile Ranks or Percentiles aggregation.

Details

1. In old version it was allowed an empty value, but under the hood the 0 value was sent to the model instead of undefined or empty string. I think it's not clearly for a user, so I made a value field is required: the user has to enter a value or remove an empty field. (cc/ @cchaos @timroes )

2. If values are not specified, a value with 0 is displayed by default.

3. If there is the only value, the remove button is disabled.

4. If entered value is not within the defined range, an error message will be displayed under that value field.

5. If the values should be in ascending order (as it's by default, e.g. for Percentile Ranks) and if they are not in such order, an error message will be displayed under the all values

6. The old number-list directive supported several additional keyboard shortcuts: shift-up/shift-down increases/decreases by 0.1, shift-enter adds a field, backspace and delete allow to remove a field when it's empty. I didn't implement them in NumberList component because
   a) there is no any mention about such keyboard possibility (I don't think that users used them),
   b) such hot keys support should be more common, probably Percentile Ranks and Percentiles in TSVB should also have the same keyboard shortcuts, or even EuiFieldNumber might support shift-up/shift-down shortcuts.

This PR also contains removal of the directives that are not used anymore:

• kbnNumberList (src/legacy/ui/public/agg_types/number_list/number_list.js)
• kbnNumberListInput (src/legacy/ui/public/agg_types/number_list/number_list_input.js)

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

• [ ] This was checked for cross-browser compatibility, including a check against IE11
• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• [ ] Documentation was added for features that require explanation or tutorials
• [ ] Unit or functional tests were updated or added to match the most common scenarios
• This was checked for keyboard-only and screenreader accessibility

For maintainers

• [ ] This was checked for breaking API changes and was labeled appropriately
• [ ] This includes a feature addition or change that requires a release note and was labeled appropriately

[cchaos]

Ok, we can delay no. 1 & 2 for now, but should try to solve them before the whole EUI-ification of Visualize is done.

Thanks, LGTM!

[timroes]

With regards to 1. @cchaos I am not so sure if we should fix that for the old editor. The problem here is that a field is just a regular parameter to the aggregation the same as any other parameter. Currently when switching aggregations we'll reset all parameters, since they might not make sense on the new aggregation anymore or even worse: there might be a parameter with the same name, but expecting different input (e.g. the interval on the different histogram aggregations). If we want to keep the field (and we have the same issue there, the field valid for one aggregation might not be valid for another), we would need to build some very special handling for that parameter, that by itself is not really different (from a technical point of view) than any other parameter. So basically we would look for a parameter named field trying to keep it's value, but basically manually must trigger validation for it, since we don't know if the same field is still valid, and if we can reuse manually trigger the change behavior for the field, so the aggregation is setup correctly. This sounds like some unpleasant and hard to maintain code in the end, which I am not sure if we want to introduce it. I totally agree that it would be better usability, but the old editor was just not build that way, and I am not sure if we should hack that special behavior still into it, or rather wait for the new visual editor to solve those general usability issues (don't select aggregation before field) for the users.

[wylieconlon]

I haven't done a really thorough code review, but checked out locally and the functionality is basically working. I had some issues using Percentile Ranks but I think that might be user error.

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[wylieconlon]

LGTM, compared against functionality on master

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request