[Logs UI] Use dedicated configuration saved object

[weltenwort]

📓 Summary

We want to separate the saved object type that stores Logs UI source configurations from the saved object type that stores Metrics UI source configurations. As a first step, the former will be stored in a newly introduced saved object type infrastructure-monitoring-log-view while the latter will continue to use the infrastructure-ui-source type.

While doing so the "source configuration" concept can be renamed to "log view" to foreshadow their extended usage and the log view management can be implemented using a LogViewService to align with the recommended Kibana plugin architecture.

part of #120920

✔️ Acceptance criteria

• A new space-aware saved object type with type id infrastructure-monitoring-log-view is registered with Kibana.
• A new runtime type logViewRT is defined which can be used to decode and encode the log view API payloads and the saved object attributes, which include a subset of the attributes of the infra source config:
  • name
  • description
  • logIndices
  • logColumns
• A static type LogView is derived from that runtime type.
• A new service LogViewService is introduced in the infra plugin.
• That new service allows for retrieval of log source configurations such that...
  • the lookup order is
    • saved object of type infrastructure-monitoring-log-view with an origin of stored.
    • internal log source configuration with an origin of internal.
    • infra source configurations as handled by the InfraSource lib with origins infra-source-stored, infra-source-internal, and infra-source-fallback respectively.
  • saving log source configurations only writes to the new saved object type.
• The infra plugin provides a defineInternalLogView via its setup() contract, which allows for registration of internal log views akin to the existing defineInternalSourceConfiguration.
• The existing callers of defineInternalSourceConfiguration that use it for configuring log-specific settings use the new defineInternalLogView instead.
• The log source API uses the new service instead of the old InfraSources to read and write saved objects.
• Other log-related APIs (such as the log entries API) also make use of the new service instead of the old InfraSources.

💡 Background

Current source config lookup and update order

• Lookup favors internal over stored
• Writing to override internal is prevented

Future log view lookup and update order

• Lookup favors stored over internal, allowing for customization of internal views by the user
• Lookup renames the previous origins to infra-source-internal, infra-source-stored, and infra-source-fallback when falling back to the old saved objects.
• New PATCH operations only ever update the new dedicated log view saved objects.

[elasticmachine]

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