[Logs UI] Allow for plugins to inject internal source configurations

[weltenwort]

Summary

This exposes an API on the Kibana server object (old platform style) to define internal source configurations, which can not be edited by the user and take precedence above any stored configurations.

The API consists of the server.plugins.infra.defineInternalSourceConfiguration(sourceId, sourceProperties) function, which is supposed to be called from the init or postInit callback of plugins to define the source configuration with a unique source id. This source id can then be used when linking to the Logs UI to enforce usage of the internal source configuration without interference by other user-defined configurations. If it is not specified, the usual "default" source configuration will be used.

More specifically, the link-to log routes now support specifying a source id in the url as in /link-to/:sourceId/logs and /link-to/:sourceId/(host|pod|container)-logs. For these log links, this is turned into the appropriate url params. It is implemented for the snapshot and metrics redirects until these pages fully support referencing non-default sources.

closes #30792

Example Usage

In a plugin definition, the postInit callback could look something like this:

const MY_PLUGIN_INFRA_SOURCE_ID = 'internal-my-plugin';

export const myPlugin = kibana => new kibana.Plugin({
  // ...
  postInit(server) {
    const infraPlugin = server.plugins.infra;
    if (infraPlugin) { // the infra plugin might not be present
      infraPlugin.defineInternalSourceConfiguration(MY_PLUGIN_INFRA_SOURCE_ID, {
        name: 'Special Logs',
        logAlias: 'a-special-filebeat-index-*',
		fields: {
          timestamp: 'a.different.timestamp.field',
        },
        logColumns: [
          {
            timestampColumn: {
              id: '5e7f964a-be8a-40d8-88d2-fbcfbdca0e2f',
            },
          },
          {
            fieldColumn: {
              id: '6ba2855d-e2b7-4f1d-aa3c-aedabee25427',
              field: 'a.special.field',
            },
          },
          {
            messageColumn: {
              id: 'b645d6da-824b-4723-9a2a-e8cece1645c0',
            },
          },
        ]
      });
    }
  },
  // ...
});

Then on the front-end, the plugin's UI could link to that source:

<a href={`${basePath}/app/infra#/link-to/${MY_PLUGIN_INFRA_SOURCE_ID}/logs?filter=${specialFilter}`}>View special logs</a>

The user would not be able to change the configuration through the configuration UI, because it would be fully controlled by the plugin.

Review Notes

• This introduces a use_url_state hook, which is essentially a port of the previous <UrlStateContainer> component to hooks, but simpler. It behaves similar to a setState hook backed by the rison-encoded url. It doesn't provide any imperative onChange callback anymore, because that can be easily be imitated using useEffect. Both the hook and the old container component use the same encoding and can be used simultaneously.
• The old react-router v4 package we're using doesn't support new-style context. In order to support access to the location, the history object is therefore now also made available via the context using HistoryContext.Provider.
• Since the log entry state and loading side-effects are still managed in redux while the sourceId state is managed via hooks, I added a bridge component on the logs page to inject the sourceId into redux land via a simple setSourceId action.
• The source configuration datastructure now has an additional property origin, which is one of internal, fallback or stored, to indicate where the configuration comes from. If it is internal, then saving through the configuration flyout is disabled.

Testing

One possibility to test whether using an internal source actually works is to add something like shown in the example usage above to one of the other x-pack plugins and directly visit the corresponding link-to route in the browser.

It's also important to ensure that not specifying any source id defaults to the "default" source id and preserves the previous behaviour.

Checklist

• 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

[elasticmachine]

Pinging @elastic/infrastructure-ui

[elasticmachine]

💚 Build Succeeded

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

[elasticmachine]

💔 Build Failed

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

[elasticmachine]

💚 Build Succeeded

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

[elasticmachine]

💔 Build Failed

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

[elasticmachine]

💚 Build Succeeded

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

[elasticmachine]

💚 Build Succeeded

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

[weltenwort]

Sorry to any reviewers who might have already started taking a look at this. Just after ending the draft state of this PR I noticed that I should really improve and simplify the "link-to" urls. I switched them around from /:sourceId/link-to/ to /link-to/:sourceId for aesthetic reasons and because I could ensure that the URL didn't accidentally cover the node-details redirects too.

The change was local to the link-to page components and didn't impact the rest of the changes.

[elasticmachine]

💔 Build Failed

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

[weltenwort]

jenkins, test this

[elasticmachine]

💔 Build Failed

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

[elasticmachine]

💚 Build Succeeded

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

[weltenwort]

The CI failure seems to have been unrelated and a rebase on master resolved it. Ready for review (again).

[simianhacker]

LGTM... @weltenwort and I discussed adding a follow up PR to add some tests around useUrlState hook. I also set up a custom source and used it with in the app and everything worked as expected. Good Job!