[Log Explorer] Add filter controls customization point

[weltenwort]

📓 Summary

We want to offer curated filters by well-known fields using the unified input control group. While the filters will be curated for individual datasets in the future, we want to start out with a persistent namespace filter.

• 🛑 blocked by: [Logs+] Implement Logs Dataset selector #159907

✔️ Acceptance criteria

• There is a customization point below the data stream picker and search bar.
• In the default profile it doesn't render anything and doesn't take up space.
• In the log explorer profile (profile id to be determined)...
  • it renders an input control group.
  • there is a pre-defined options list control, in the control group that filters for the data_stream.namespace field in the currently active data view.
• There is a way in which the control group filters can be injected into the search source, e.g. a getFilters callback in the customization interface that is called before fetching.
• There is an example usage for the new customization point in examples/discover_customization_examples and a test for that example in test/examples/discover_customization_examples.

🎨 Mock-ups

⚠️ these mock-ups are just for illustration purposes and don't exactly represent the desired outcome

[elasticmachine]

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

[elasticmachine]

Pinging @elastic/kibana-data-discovery (Team:DataDiscovery)

[ThomThomson]

@elastic/kibana-data-discovery tagging this with both of our teams as we may need to work together to get the Controls working nicely with Discover.

[weltenwort]

@ThomThomson currently the idea was for us to add a customization point to Discover to plug our custom filter controls into. That would get your team off the critical path for now, but leaves open the option of moving it from a customization point into a native search bar or Discover feature in the future. Does that make sense for you?

[ThomThomson]

Sounds good @weltenwort! We'll keep our tag on this to keep an eye on it for the time being.

[davismcphee]

PoC of this work for reference: #159318

[weltenwort]

Options for persisting the controls

The POC created by @davismcphee already goes a long way to show what the extension point will probably look like. While it's out of scope for this issue, we should try to think ahead about how we will allow integrations to ship dataset-specific controls. This might influence how we design the API that injects filters into the search source.

Option A: input controls in unified search and search sources

If the unified search bar natively supported control groups the controls could be persisted in the serialized search source:

• persisted in serialized search source JSON blob
• automatically included in the request
• complex change, because it's widely used throughout Kibana
• has been rejected before

Option B: persist control groups in saved search

The control group definition and filter values could be persisted in the saved search and passed to the control group component when the saved search is loaded.

• persisted in a saved search attribute, local to Discover
• filters must be injected into the search source as shown in the POC
• requires synchronization code from filters to control groups and back

Option C: persist control group embeddable state in saved search

Since a control group can be consumed as an embeddable, we could also store the embeddable state in the saved search.

• persisted in a saved search attribute, local to Discover
• filters must be injected into the search source as shown in the POC
• requires synchronization code from filters to control groups and back
• automatically migrated using the embeddable's persistable state

Option D: read control group state from integration

Since the dataset selector is supposed to be the bridge between fleet and Kibana's analytics apps, it could also read the control group definitions from any asset of an integration via a fleet API and inject it into the control group elements.

• persisted in any package asset or manifest
• filters must be injected into the search source as shown in the POC
• requires synchronization code from filters to control groups and back
• read-only unless we implement extra fleet package mutation APIs

[weltenwort]

• 🔗 related to option A: [Unified Search] Comparison & opinionated controls in unified search #135735