Options list control should not search on formatted numbers

[toby-sutor]

Kibana version: 7.13.1

Describe the bug:
If we create an (experimental) "options list" control in the visualization app, then the format:number:defaultPattern is applied to this control. While this is feasible when displaying data, it is not when searching for data.

For example, looking at the Kibana sample logs data machine.ram field, which is a number, in a format like 20401094656:

It is displayed in the control with a thousands separator (,):

The problem is that when searching for a value, for which I would intuitively use the raw value, we now need to provide the formatted value as otherwise it does not match:

The workaround is to change the format:number:defaultPattern in the Kibana advanced settings from the default 0,0.[000] to 00.[000]:

Since this setting is Kibana global and affects other features as well (where the behavior is indeed desired), I think that this should be changed. Either do not apply number formation to search fields or make them more lenient when searching for the raw-values. Not sure if this is perhaps related to #39211.

[elasticmachine]

Pinging @elastic/kibana-app-services (Team:AppServices)

[Dosant]

Probably related: #83858

[elasticmachine]

Pinging @elastic/kibana-presentation (Team:Presentation)

[rom1b31]

Kibana version: 7.13.4

Describe the bug:
It seems that the following behavior could have the same root cause.
Creating an (experimental) "options list" control in the visualization app linked to a keyword field that is not case-sensitive:
Mapping is:

   ...
   "template" : {
      "settings" : {
         "analysis": {
            "normalizer": {
               "uppercase_normalizer": {
                  "type":"custom",
                  "filter":[ "uppercase", "asciifolding" ]
               }
            }
         }
      },
      "mappings" : {
         "properties" : {
            "Name" : { "type" : "keyword", "ignore_above" : 512, "normalizer":"uppercase_normalizer" }
   ...

Then when I enter 'AA' (uppercase) in the field of the options list control, there are results

But when I enter 'aa' (lowercase), results appears as above briefly and then the following message replaces the list:

aa doesn't match any options

Looks like if query takes into account the normalizer but the "option list" control overrides the behavior

[elasticmachine]

Pinging @elastic/kibana-vis-editors @elastic/kibana-vis-editors-external (Team:VisEditors)

[flash1293]

Removing viseditors label as this is about input controls owned by the presentation team

[Heenawter]

Related to #126795

Closing - while this is something to consider when we implement number fields in the new options list control, the old input controls are now deprecated and therefore this will not be fixed there 👍