feat: fix metric classes and add default-aggregation to all metrics

[k-rister]

Summary

• mpstat/pidstat: migrate Busy-CPU and NonBusy-CPU from class=throughput to class=percentage — these are 0-1 CPU utilization fractions, not throughput rates
• iostat: migrate percent-utilization from class=throughput to class=percentage
• iostat: migrate percent-merged from class=count to class=percentage
• iostat: migrate avg-service-time-ms from class=count to class=latency
• Add explicit default-aggregation to all metric descriptors: sum for throughput rates, avg for percentages/latency/counts

Part of PERFNFV-421 / epic PERFNFV-409

Test plan

• Run benchmark with sysstat tool, verify class assignments on mpstat/pidstat/iostat metrics
• Verify all metrics have default-aggregation in metric_desc documents

🤖 Generated with Claude Code

[atheurer]

Approving per team decision, but flagging the concern found during review: default-aggregation is written directly into the metric_desc document, but CommonDataModel's metric_desc index mapping is dynamic: strict and only declares class/type/source/names-list/names — an aggregation field (aggregation-method, a different name) is called out in cdm.js as planned for a future schema version but not yet enabled. This could cause metric_desc writes to be rejected by OpenSearch under strict mapping.

This same field is being added in parallel by several other PRs (tool-dpdk#9, bench-fio#67, bench-pytorch#15, bench-hwlatdetect#16, bench-hwnoise#21, bench-oslat#89, bench-osnoise#18, bench-timerlat#14) — recommend verifying CDM schema support once, centrally, before any of these land in production, rather than per-repo.

Also noting the new percentage/latency class values used here are novel relative to other tool-* repos (which mostly use throughput/count/logging/pass) — worth confirming CDM's aggregation logic actually branches on these values.

[atheurer]

Correction to my earlier approval comment: I checked upstream CommonDataModel and default-aggregation IS already declared in the metric_desc index mapping (templates/metric_desc.base, type keyword — added in CDM PR #202). Despite dynamic: strict, this field is explicitly mapped, so it will not be rejected by OpenSearch. Retracting that concern. The note about percentage/latency being novel class values relative to other tool-* repos still stands as a minor consistency observation, not a blocker.