[Usage collection] move plugin to core

[Bamieh]

Summary

Usage collection plugin exposes apis for other plugins to send telemetry from the browser and server. Having these apis exposed via a plugin instead having it as a core service has several drawbacks:

1. Usage collection is a core service, owned by the core team, and used by most kibana plugins.
2. Currently we have a 'hacky' way to send core usage. since core is initialized before the usage plugin we need to kindof hydrate the data after plugins are setup.
3. (tiny nit) Usage collection cannot be disabled

Is this a breaking change?

No. We do not recommend or document this API for outside contributors. Any usage sent by external plugins is not used at Elastic.

Is this a big change?

Yes. The following steps are required to complete this task:

• Moving the plugin and integrating it into core as a service.
• (Separate PR) Rewiring plugins to drop the usage collection plugin and using the core service.
  • If we do not want to do this step in the same PR we can keep the plugin as a placeholder that only returns the core.usageCollection contracts.
  • The drawback here is that we'd need to communicate with teams to do this themselves within the next releases.
• (Separate PR) Removing the core_usage service and using the usage_collection service in core instead.

[elasticmachine]

Pinging @elastic/kibana-telemetry (Team:KibanaTelemetry)

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[pgayvallet]

Moving the plugin and integrating it into core as a service.

(Separate PR) Rewiring plugins to drop the usage collection plugin and using the core service.

How will we manage the transition period if we do that in 2 steps? Will the usage collection plugin bridge to the new core service during this time?

[Bamieh]

Will the usage collection plugin bridge to the new core service during this time?

Yes just directly returning the core.usageCollection contracts from the plugin should be enough during that period

[afharo]

I started doing so long ago (#69306) but closed the PR because we changed our plans.

I'd be happy to dust off those changes again :)

[afharo]

Alternative approach: how about moving the APIs to a Package? Would it be possible?

[pgayvallet]

how about moving the APIs to a Package? Would it be possible?

I don't know the usage collection internal implementation that well, but it's using core services, right? I'm guessing at least savedObjects. Moving usage collection to a package means that it would still require to be instantiated from a plugin or from core to connect it to the core services it requires to function. Plus, the core service's types being in src/core/server, it would require an additional level of abstraction between core interfaces/types and the ones required by usage collection, as packages can't import anything from src/...

Given that, I'm not sure there would be any upside compared to moving it to core?