Add metric value type everywhere (as code-generation annotation)

[lmolkova]

Fixes #591
This PR adds value_type (int or double) to all metric definitions and updates template to render it in the metrics table.

All MD changes are auto-generated, all substantial changes are in yaml

[Copilot]

Pull Request Overview

Adds a new value_type attribute to every metric and surfaces it in both the rendered registry table and documentation.

• Updated the registry template to include a “Value Type” column.
• Added value_type (int or double) to all metric definitions in YAML.
• Regenerated all Markdown docs to show the new column.

Reviewed Changes

Copilot reviewed 62 out of 62 changed files in this pull request and generated 4 comments.

File	Description
templates/registry/markdown/metric_table.j2	Add “Value Type” column to metrics table macro
model/**/*.yaml	Insert value_type into each metric group
docs/system/*-metrics.md	Update Markdown tables to include Value Type column

[trask]

I also have similar question as you about when cpu count should allow for millicores and when it shouldn't

E.g. jvm.cpu.count is captured using https://docs.oracle.com/javase/8/docs/api/java/lang/Runtime.html#availableProcessors-- and so can only be an int, but there could always be a new Java API in the future that is container aware and allows capturing in millicores (e.g. https://openjdk.org/jeps/8182070)

although I think it's not a breaking change to switch between int and double, since there's no difference in the OTLP output, so future proofing may not be so important?

[braydonk]

Verified for process and system.

[joaopgrassi]

Thank you!

[lmolkova]

based on the SIG call discussion:

• metric value type is explicitly called out as something that can change - https://github.com/open-telemetry/opentelemetry-specification/blob/ac137b349b006dc926da91c6a6619217737921cc/specification/versioning-and-stability.md?plain=1#L260
• we can still have a hint defined for codegen reasons - this is what annotations are for

so, I repurposed this PR to use annotations.code_generation.metric_value_type

E.g.

  - id: metric.system.process.count
    type: metric
    metric_name: system.process.count
    annotations:
      code_generation:
        metric_value_type: int

[jerbly]

See open-telemetry/weaver#817 (comment) - all is not lost. Since annotations are part of the resolved registry they are also passed through to custom rego policies you can provide to live-check. So, it is still possible to check telemetry aligns with model.