feat(opa-gson): add MetricsTypeAdapterFactory mirroring opa-jackson #59

[sanajitjana]

Fix issue #59

Summary

Adds MetricsTypeAdapterFactory to opa-gson, closing the parity gap with
opa-jackson's MetricsModule.

Changes

• MetricsTypeAdapterFactory — serializes Metrics.Timer as nanoseconds,
  Metrics.Counter as int, Metrics.Histogram as its Values object
• MetricsTypeAdapterFactoryTest — parallel tests to MetricsModuleTest

JSON Shape

Matches DecisionLogPlugin's output:

{"timer_rego_query_eval_ns": 12345}

[sspaink]

@sanajitjana thank you for working on this! can you sign your commits please for the DCO check to pass?

[sanajitjana]

@sspaink - it's done now.

[sspaink]

Timer JSON shape diverges from the opa-jackson MetricsModule this mirrors.

This emits nanoseconds as an integer (12345), but opa-jackson serializes Metrics.Timer as its Duration via @JsonValue, which with JavaTimeModule produces fractional seconds — a 12345 ns timer yields 0.000012345. So a consumer who swaps mappers gets a structurally different value for the same timer, which cuts against the "close the parity gap" goal of the PR.

The nanosecond shape here is the correct one: it matches DecisionLogPlugin (timer.value().toNanos()) and OPA's canonical decision-log format, where the timer_<name>_ns key declares the unit as nanoseconds. jackson's fractional-seconds output is effectively a unit mismatch under that key, so opa-jackson is the module that should change — not this one.

So: keep this gson adapter as written, and align opa-jackson's MetricsModule to emit nanoseconds too (e.g. a JsonSerializer<Metrics.Timer> or a @JsonValue method returning value().toNanos(), plus updating MetricsModuleTest to assert against toNanos()). That also drops the JavaTimeModule requirement on that path.

@sanajitjana if you have the time, would you mind folding that jackson fix into this PR so parity is actually true when it lands? No pressure — if you'd rather keep this PR scoped to gson, I'll follow up with the jackson change separately.

[sspaink]

CounterAdapter and HistogramAdapter (below) ship with zero test coverage.

MetricsTypeAdapterFactoryTest only exercises the Timer path, and SimpleMetrics.counter(...)/histogram(...) both return null, so there is no in-tree implementation that produces a non-null Counter or Histogram. That leaves the int-counter path and the whole Histogram.Values field layout (via gson.getAdapter(Values.class)) unverified.

Consider adding one test per adapter using a small hand-built Metrics.Counter/Metrics.Histogram stub — these are the paths that go beyond what opa-jackson's MetricsModule covers, so they're the most valuable to pin down.