[Logs] Improve field selection for breakdown for Logs Explorer

[ruflin]

Currently if a user clicks on "Break down by" the list of all available fields is shown. For logs explorer in combination with ECS / semconv, we can be opinionated about which fields users likely want to break down the graph. As mentioned in #166595, the default should be log.level, but there are potentially other fields users will want to see the breakdown to understand what creates how many log messages. The proposed fields are:

• service.name
• host.name

It is expected that this list will get expanded with more fields for example in the k8s use case where it might be per pod / node.

The general idea is, having 5-10 fields suggested on the top. If a user really wants to break down by other fields, it should be possible but not shown by default. @isaclfreire We will need ideas on the UX here. Likely this is a similar problem to the field list on the left bar in the logs explorer.

[elasticmachine]

Pinging @elastic/infra-monitoring-ui (Team:Infra Monitoring UI)

[elasticmachine]

Pinging @elastic/obs-ux-logs-team (Team:obs-ux-logs)

[isaclfreire]

The Discover team will be introducing a different breakdown menu as part of their Discover design refresh (see the one in the left). The main changes I can see are:

• The introduction of a search bar
• Set the number of fields shown to 5
• The possibility of choosing 'no breakdown'

I edited the component with the fields suggested (see the one in the right). My questions are:

• Do we want to provide 'no breakdown' as well?
• Should we notify the user which one is the default field? (log.level)
• Is it self-explanatory enough that the list is just a selection and users can search any other available field as well?

[ruflin]

• To keep things aligned, I would add the "no breakdown" section too.
• Notify user: What you mean by that exactly? You mean the default part? If we indicate it, it kind of implies a user can change it?

It seems the type icons are new. What is the value this info provides in this context? If none, I would leave it out.

[gbamparop]

I think it would make sense to follow the same design and use the component provided, if possible, and just provide our suggested fields to have consistent experience if we don't aim to differentiate much. We could provide our feedback to the current designs