Remove telemetry_collection_manager in favour of a better X-Pack extension API in the telemetry plugin

[afharo]

The reason for telemetry_collection_manager was to provide a set of APIs to add priority-based collection. This helped us to attempt monitoring collection before rolling back to the local (X-Pack or OSS) methods.

Now, monitoring collection doesn't count as a strategy on its own, and X-Pack simply replaces OSS when available. This can be handled in a better way directly in the telemetry plugin, reducing the need for a separate plugin.

[elasticmachine]

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

[Bamieh]

We can create a new collector type next to createUsageCollector called createRootCollector or createProductCollector which appends the data to stack_stats.* instead of stack_stats.kibana.plugins.*. Then we can start enforcing schema there too.

Alternatively we can utilize createStatsCollector to achieve this.

[afharo]

I like that idea, but I wonder if it fits best with this other issue #89709. What do you think?

I think for this purpose, we can do something similar to the SavedObjectsClient security extension. We have a defaultFactory for OSS, and X-Pack can extend that defaultFactory. I hope it makes sense.

[Bamieh]

i dont mind it if we come up with a good execution plan. Generally I think we dont really need to complicate thing since our usecase is very simple straightforward in terms of what we want to do between the xpack plugin and the oss one.

[afharo]

After the relicensing, we probably don't need to maintain the X-Pack extension anymore. We could use this issue to migrate the X-Pack specifics to the OSS telemetry, and remove the telemetry_collection_manager plugin entirely.

What do you think?