Overhaul stats: Refactor metrics, use label metrics to calculate global metrics

[josecelano]

The idea is to continue exposing the stats endpoint but removing the internal code to calculate them. Instead, we calculate the metrics from the labeled metrics.

That will simplify the event listeners and avoid duplicate code to calculate the same data.

Endpoints for statistics

stats (simple predefined global metrics)

• http://localhost:1212/api/v1/stats?token=MyAccessToken&format=json
• http://localhost:1212/api/v1/stats?token=MyAccessToken&format=prometheus

metrics (extendable-labelled metrics)

• http://localhost:1212/api/v1/metrics?token=MyAccessToken&format=json
• http://localhost:1212/api/v1/metrics?token=MyAccessToken&format=prometheus

Subtasks

• Add a new method to MetricCollection to sum the metric's samples.
• Review test coverage.
• Use the new method to calculate metrics in the stats endpoint.

After merging this PR

• Deploy to the tracker demo and verify that both Grafana dashboards appear identical.
• Delete unused code to calculate the metrics in the stats endpoint directly in the event listeners.
• Redeploy to the tracker demo and re-verify.

NOTICE: We have two Grafana dashboards, one collecting data from the stats endpoint and another collecting data from metrics, and they look identical now. If there is a bug in the way we calculate aggregate values in the MetricCollection, we should see different graphs in the dashboards.

Both dashboards (built from stats on the left, built from metrics on the right):

NOTICE: Also, the new methods will be helpful for external users once we publish the metrics crate. Consumers of the Torrust Tracker API (metrics endpoint) will be able to deserialize and calculate aggregate values from the response.

[codecov]

Codecov Report

Attention: Patch coverage is 98.85774% with 11 lines in your changes missing coverage. Please review.

Project coverage is 84.79%. Comparing base (c3dffa5) to head (dcfb5d5).
Report is 9 commits behind head on develop.

Files with missing lines	Patch %	Lines
...s/rest-tracker-api-core/src/statistics/services.rs	98.18%	4 Missing ⚠️
.../http-tracker-core/src/statistics/event/handler.rs	50.00%	2 Missing ⚠️
packages/metrics/src/metric/aggregate/sum.rs	98.97%	2 Missing ⚠️
packages/primitives/src/service_binding.rs	92.30%	2 Missing ⚠️
...r/src/statistics/event/handler/request_accepted.rs	0.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #1577      +/-   ##
===========================================
+ Coverage    84.15%   84.79%   +0.64%     
===========================================
  Files          286      289       +3     
  Lines        20789    21712     +923     
  Branches     20789    21712     +923     
===========================================
+ Hits         17495    18411     +916     
- Misses        2974     2984      +10     
+ Partials       320      317       -3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[josecelano]

[josecelano]

I've been considering removing the traits:

src/metric_collection/aggregate.rs:

pub trait Sum {
    fn sum(&self, metric_name: &MetricName, label_set_criteria: &LabelSet) -> Option<AggregateValue>;
}

src/metric/aggregate/sum.rs:

pub trait Sum {
    fn sum(&self, label_set_criteria: &LabelSet) -> AggregateValue;
}

I wanted to keep MetricCollection and Metric types unaware (decouple) from the aggregate functions. So:

• You can add more aggregate functions without adding more methods.
• Aggregate functions don't need access to the internals of those types. They only need to get the values (iterate).

However, I tried to do the refactor, and I ended up with something like:

/// Calculate the sum of metric samples for a given metric name and label criteria.
/// 
/// This function follows the Open/Closed principle by allowing new aggregate functions
/// to be added without modifying the MetricCollection type.
pub fn sum(collection: &MetricCollection, metric_name: &MetricName, label_set_criteria: &LabelSet) -> Option<AggregateValue> {
    // Direct implementation without trait dependency
    if let Some(counter_collection) = collection.counters.metrics.get(metric_name) {
        return Some(counter_collection.sum(label_set_criteria));
    }
    
    if let Some(gauge_collection) = collection.gauges.metrics.get(metric_name) {
        return Some(gauge_collection.sum(label_set_criteria));
    }
    
    None
}

The problem with this approach is that the aggregate function will be broken as soon as we add a new type of metric to the metric collection.

It doesn't work for the metric collection, but it could work for the metric.

Anyway, since we only have one aggregate function, I will keep it as it is for now. We can reconsider other alternatives if we plan to add more aggregate functions in the future.

cc @da2ce7

[josecelano]

ACK dcfb5d5