Fix GPU task metric unit inference

[amahussein]

Fixes #2136

Summary

AppSparkMetricsAnalyzer decided a GPU metric's unit, its scale and its aggregation by testing substrings of the metric's own name. That information belongs to the accumulator emitting the metric, not to the string naming it, so the guesses were wrong in five ways. On a profiled application whose stage carries 17 GPU accumulables, gpu_stage_level_aggregated_task_metrics.csv emitted 9 rows.

The worst of it was silent. Every timing metric was divided by a million a second time, because parseAccumFieldToLong had already converted the plugin's "00:00:01.773" form to milliseconds; the values floored to zero and the rows were then deleted by the zero-signal filter. "Wait" matched inside "Waiting", so three counters were scaled away the same way. gpuMaxTaskFootprint was labelled count because its name lacks the word Bytes. avg was hardcoded empty for max-aggregated metrics, discarding the mean across tasks of each task's own peak. And gpuOnGpuTasksWaitingGPUAvgCount, a Double-valued accumulator no parse branch could read, did not merely go missing: the stage path substituted a zero and published it, so the file reported an empty GPU wait queue on stages whose true peak was 7.

This replaces the substring rules and the hardcoded max-aggregate set with a declarative catalog, configs/metrics/metricCatalog.yaml, carrying one entry per metric with its family, unit, value form, storage scale and aggregation. Adding a metric is a YAML edit. convertValue is deleted rather than reworked, since the parser already normalises every serialised form to a canonical unit and nothing downstream should convert again. A metric absent from the catalog is still discovered by name prefix and falls back to the old heuristic for its unit label only, which is now harmless because no value is scaled by it.

The decimal metric is stored as fixed-point thousandths and divided out at render, so avg survives the integer store. Rounding it instead leaves the mean reading zero, and widening StatisticsMetrics to Double changes 44 of 83 median cells in an existing expectation file.

What changes in the output

The stage file goes from 9 rows to 17. gpuTime reappears at 417,903 ms summed with a 29,623 ms worst task, gpuMaxTaskFootprint becomes bytes, and gpuOnGpuTasksWaitingGPUAvgCount reads max=2.5, avg=0.72 where stage_level_all_metrics.csv previously showed 0,0,0,0. The SQL and app rollups inherit the same corrections. Row counts are unchanged, so no stage entries are fabricated, and a CPU event log still emits no gpu_* file.

Because one metric now renders fractional cells, the report contract retypes ten columns from Long to Double. This is a Python-side declaration only; values remain Long throughout the Scala. sum stays Long, since the only decimal metric is max-aggregated and its sum is always empty.

Qualification is unaffected. I built the parent commit and diffed both tools' output on a CPU log and a Photon log: byte-identical apart from one new warning naming an accumulable no parser can read, which was previously dropped in silence.

Testing

883 tests, 0 failures. Scalastyle and the Scala 2.13 cross-build are clean.

parseAccumFieldToLong had no unit test at all. There are now cases pinning each parse branch's output unit, the fixed-point scaling, the overflow boundary on both signs, and the inputs Double.parseDouble wrongly accepts. AnalysisSuite no longer re-implements the unit rule as its own expectation nor keeps a private copy of the max-aggregate set, and it asserts that every GPU accumulable carrying a non-zero value produces a row, which is the assertion whose absence let eight metrics vanish unnoticed.

[parthosa]

Thanks @amahussein. LGTME.