Move Telemetry `UsageCountersService` into core

Summary

Moving the Usage Counters Service inside core allows Core services to use it at its full potential.

Examples of use cases that could benefit from having the Usage Counters Service available to core services:

1. HTTP API usage
2. Feature Flags variations

Justification (Internal notes)

In Core, we've identified many scenarios where we'd like to leverage the Usage Counters Service to report the level of usage of core services (or features registered via core APIs).

In the past, we've addressed this issue in 2 ways:

1. The Analytics Service emits the counters via an observable, and another plugin increments Usage Counters accordingly
2. We've registered a preinstantiated counter, so that Core services can increment counters.

These approaches have their downsides:

1. Exposes information to external plugins. The data exposed is not critical, but it's not an ideal solution.
2. The registered counter is scoped to a single domain core, meaning that we have to use counterType to specify the subdomain (http, feature-flags, analytics, status), leaving us with only 1 field, counterName, to tag the counter, which limits a lot the ability to report telemetry.

If we move UsageCountersService inside core, we can use it at its full potential.

Goal (definition of done)

• Core services can create Usage Counters and are able to use the 3-level attributes (domain, counterName, and counterType) to create different time series if required.
• Snapshot Telemetry documents include this information.
• Existing consumers do not require changes.

Out of scope

• Migration of existing consumers of the Usage Counters
• Migration of existing core services reporting Usage Counters
• Migration of the Saved Object APIs ad-hoc usage counters
• Update documentation to point to the new core service instead of the Usage Collection APIs.

Implementation details

Rather than embedding it inside the coreUsageData service, I'd create a new core service, so that it can be used straight from core for future integrations, without depending on the Usage Collection plugin.

The current usageCollection plugin could still re-export the APIs to avoid introducing breaking changes to existing consumers.

Links

Related https://github.com/elastic/kibana/issues/101146

Timing

This effort should be time-boxed to 1 week. If it requires more than that, it's not worth the added value.

Roles

Owner: @afharo (or @Bamieh) Contributor: @TinaHeiligers