fix(metrics): implement SimpleMetrics counter and histogram

[c879873067877881111]

Fixes #60

Summary

SimpleMetrics only implemented Timer. histogram(String) and counter(String)
returned null, so any caller of those metric types threw an NPE, and all()
returned only the timer map, so neither type ever reached MetricsPrinter.

Changes

• Counter backed by an AtomicInteger. The issue suggests AtomicLong/LongAdder,
  but Metrics.Counter declares add(int) and int value(), so a long accumulator
  would only add a lossy narrowing at the boundary.
• Histogram over a bounded reservoir of 1028 samples — the size Go-OPA takes from
  rcrowley/go-metrics — replacing a random slot once full, so a long-lived Metrics
  instance cannot grow without bound. Statistics follow the Go implementation:
  population standard deviation (SampleVariance divides by N) and the linearly
  interpolated SamplePercentiles, at Go's hardcoded set (median, 75%, 90%,
  95%, 99%, 99.9%, 99.99%). count is the number of updates, not the reservoir
  occupancy, matching snap.Count().
• all() and clear() now cover all three metric types.
• Histogram.Values keeps its int fields, so the rows MetricsPrinterTest asserts
  are unchanged.
• The timer map and the inline Timer are untouched — that is Make SimpleMetrics thread-safe #56. The new
  counter/histogram code is thread-safe as written.

Verification

• ./gradlew :opa-evaluator:test :opa-evaluator:checkstyleMain :opa-evaluator:checkstyleTest :opa-evaluator:pmdMain :opa-evaluator:pmdTest — no PMD findings, and no Checkstyle
  findings for SimpleMetrics.java. SimpleMetricsTest picks up the usual MethodName
  warnings for snake_case test names, as the existing test sources do (Relax Checkstyle MethodName for test sources #88).
• Adds SimpleMetricsTest, 8 cases. Reverting only SimpleMetrics.java fails 7 of the
  8; the 8th covers clear(), which passes trivially when nothing can be registered.
• ./gradlew build: the only remaining failures are json_match_schema/invalid document
  and :opa-proto:vendorProtoSchemas. The first reproduces unchanged with my change
  reverted; the second is go mod download unable to reach proxy.golang.org from here.

Open questions

1. The issue asks for configurable percentiles, but upstream Go is explicitly "a
   histogram with hardcoded percentiles" and CONTRIBUTING asks to keep the public
   surface minimal, so I matched Go. Happy to add a constructor overload if you would
   rather have it configurable.
2. mean and stddev are float64 in Go but int in Histogram.Values, so precision
   is lost. Widening them is a public-API change that also rewrites the
   MetricsPrinterTest expectations — worth a separate issue?

[sspaink]

Now that counters and histograms are in all(), DecisionLogPlugin.buildDecisionEvent falls into its else branch and calls MAPPER.valueToTree(...) on SimpleCounter/SimpleHistogram — neither has a Jackson-visible property, so it throws No serializer found ... and no properties discovered to create BeanSerializer. DecisionLogs.logDecision swallows that as "Failed to log decision", so the entire decision event is dropped, which is the opposite of the CHANGELOG's "so they reach ... decision logs".

MetricsModule already solves this for Timer; the same mixin treatment covers the other two:

setMixInAnnotation(Metrics.Counter.class, CounterMixin.class);
setMixInAnnotation(Metrics.Histogram.class, HistogramMixin.class);

abstract static class CounterMixin {
  @JsonValue
  abstract int value();
}

abstract static class HistogramMixin {
  @JsonValue
  abstract Metrics.Histogram.Values value();
}

[c879873067877881111]

Mixins added. Testing them turned up a second path: DecisionLogs.MAPPER is a bare ObjectMapper + JavaTimeModule, and opa-jackson is only runtimeOnly for opa-services, so the mixins don't reach it — with them in place the repro still failed identically. Timers avoid it only because of the explicit timer_<name>_ns branch.
So buildDecisionEvent now writes counters and histograms itself as well, under formatKey's names, counter_<name> and histogram_<name>; unknown Metrics keep the Jackson fallback. Covered by decisionLogs_includesEveryMetricType.

[sspaink]

This can overflow. The largest value an int holds is about 2.1 billion, which is only 2.15 seconds in nanoseconds — and nanosecond timings are what Go feeds histograms in topdown/instrumentation.go. Anything bigger turns negative: update(3e9) reports -1294967296 for every stat. The line above does Math.min(count, Integer.MAX_VALUE) to avoid this; the same idea works here:

Suggested change

	return (int) Math.round(value);
	return (int) Math.max(Integer.MIN_VALUE, Math.min(Integer.MAX_VALUE, Math.round(value)));

[c879873067877881111]

The suggestion was adopted without modification.
Overflow occurs in the negative direction as well—update(-3e9) results in +1294967296; his original comment only mentioned the positive-to-negative case.
Both directions were tested; the test names are histogram_saturatesStatsAboveIntRange and histogram_saturatesStatsBelowIntRange.
I left Values as int rather than widening to Go's int64/float64.

[sspaink]

Since all three maps share one key space, reusing a name across types silently drops one. After metrics.timer("x") and metrics.counter("x"), all() returns just the counter — the timer is gone from the printer, the CLI table and decision logs. Go's All() prefixes each key by type (timer_x, counter_x), so both survive there.

Matching that means moving the prefixing out of MetricsPrinter and into all(), which is bigger than this PR — fine as a follow-up, but worth noting the gap here.

[c879873067877881111]

Agreed with all three types sharing a name, only one survives all().
Confirmed formatKey behaves as you describe. Leaving it out of this PR
Do you want to open an issue to track it?

[sspaink]

issue opened: #229)

[sspaink]

thanks!