Make data.search.aggs available on the server.

[lukeelmers]

Closes #65793

Summary

This PR is the final step to expose the aggs service on the server. At a high level, it does the following:

• Moves nearly all of the service code to common to be made available on client & server.
• Adjusts all of the imports in the relocated files.
• Creates a "common" aggs service definition with the main service contracts that are expected to be the same on both client and server.
• Creates specific client & server service definitions, which wire up any environment-specific dependencies to the underlying common service.
  • For example, on the client we interact with core.uiSettings a bit differently, and need to write some glue code to pass the correct dependencies to the common service.
  • And on the server, we need a scoped saved object client before we can even access uiSettings, so we must wrap the start contract in an async function which received a scoped client.
• Removes calculateAutoTimeExpression from setup method and only provides it during start
  • This wasn't actually used anywhere in Kibana during setup, and since it takes uiSettings as a dependency it wasn't really possible to expose it on the server during setup. So I removed it to keep the setup/start contracts the same across client and server.

It's not (quite) as scary as it looks.

This is a big PR, but not as intimidating as it looks: Since we are adding a new service on the server, about 46 markdown files were automatically generated. Additionally, the majority of files touched here were simply moved without changes, or moved while only updating import paths.

Reviewers

I tried to keep a clean commit history in hopes it would make reviews easier, but another way to approach this would be to start with reviewing the 3 different aggs_service.ts files (in common, public, and server), and then moving forward from there.

Testing

Initially the server API that is introduced here is not being used elsewhere in Kibana, so the main thing to test for would be any regressions in the browser around aggs -- these would be most likely to surface in core visualizations or lens, which are using this service behind the scenes.

Specific agg types to test which are slightly more complex in terms of dependencies and therefore more likely to break: percentile ranks, date histogram, histogram, range, date range.

Dev docs

The search.aggs service in the data plugin is now available on the server. Usage is the same as on the client, except that a scoped saved objects client must be provided on the server in order to retrieve the start contract:

const savedObjectsClient = savedObjects.getScopedClient(kibanaRequest);
// `aggs.asScopedToClient` will return the same contract as is available in the browser
const aggs = await data.search.aggs.asScopedToClient(savedObjectsClient);
const allAggTypes = aggs.types.getAll();

As part of this change, the calculateAutoTimeExpression method was removed from the setup contract, and now only exists on the data plugin's start contract. The method was unused in setup elsewhere in Kibana, so it was removed for simplicity.

In addition, the agg types registry has changed and now accepts a provider function which is used to inject dependencies which may be needed in the agg type definition, specifically a getConfig function which can be used to retrieve uiSettings:

const getMyAgg = ({ getConfig }) =>
  new MetricAggType({
    name: 'myAgg',
    expressionName: 'myAggFunction',
    getSerializedFormat: (agg) => ({ id: 'number' }),
    params: [
      {
        name: 'someParam',
        write: (agg, output, aggs) => ({
          const queryLanguage = getConfig('search:queryLanguage');
          ...etc
        })
      }
    ],
  });

// register the agg type provider
dataSetup.search.aggs.registerMetric('myAgg', getMyAgg);

We expect more changes to the agg type definition over the next few minor releases, and will add release notes indicating any future updates.

[elasticmachine]

Pinging @elastic/kibana-app-arch (Team:AppArch)

[lukeelmers]

Ideally we'd add isDefault to the uiSettings service on the server so that we don't need to manually check against the default value. I'm looking into this as an alternative.

[lukeelmers]

We need the default agg types which are in the registry to have ui settings which are scoped to the current user. However, technically 3rd party plugins can register their own agg types.

So for now we are making the assumption that 3rd party agg types are not using ui settings and therefore don't require a scoped saved objects client. This means we can store one shared copy of them in setup, and then merge everything together here.

I think this is fine for now since we don't even have known 3rd party plugins registering custom agg types right now, and they'd need to be doing it from the server anyway.

Longer term we should consider revisiting the design of the agg types and perhaps simplify things so that we could do something like give each agg type its own getConfig as a convenience, which could be used inside of the agg. But this would likely require a simpler "definition" style of registry item, similar to what we've done elsewhere (like expressions).

[lukeelmers]

Named asScopedToClient since it is consistent with core.uiSettings.asScopedToClient

[lukeelmers]

@elasticmachine merge upstream

[lukeelmers]

@elasticmachine merge upstream

[lukeelmers]

@elasticmachine merge upstream

[ppisljar]

code LGTM

[ThomThomson]

Code LGTM - focused on the changed lens test. Tested locally in Chrome, searching for regressions in lens and the visualize editor, and everything looks good.

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 5f5e4d1

Build metrics

@kbn/optimizer bundle module count

id	value	diff	baseline
data	540	+4	536

page load bundle size

id	value	diff	baseline
data	1.4MB	+29.1KB	1.4MB

History

• 💚 Build #67827 succeeded 0a1bea963e4b942b7216f53e128bab53e6d4b220
• 💔 Build #67378 failed 299ee245ca8713017150f32bc9063e46442e363e
• 💚 Build #67135 succeeded 2b14394f6dd0bffae73e03392c41aec0550eee5d
• 💚 Build #67123 succeeded 461845cf46d9aa7d37664da136e6681521c7d805
• 💚 Build #67031 succeeded 5399ef3b0fed9de93a727c9cea921e933f5e3194

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream