feat!: evaluate feature flags through the v4 endpoints

[lourens-octopus]

Resolves BMBB-753 and BMBB-749. Java counterpart of openfeature-provider-dotnet#96, brought up to date with .NET's current code.

What

The provider now evaluates through the v4 feature-flag endpoints, using the rules-based evaluation from #51 instead of v3's segment and rollout matching.

• api/feature-flags/check/v4/ and api/feature-flags/evaluations/v4/
• EvaluationResponse replaces FeatureToggles; getServerSideEvaluations() replaces getFeatureToggleEvaluationManifest()
• evaluate(slug, context) drops defaultValue and resolves a ServerSideEvaluation, so value and reason come from the server or from the rules it deferred, and a malformed response reports the problem it found
• specification submodule ef84509 → 67890d8

Two breaking changes

Both carry a BREAKING CHANGE: footer, so release-please cuts the major. Cutting the release is BMBB-772.

• The endpoints — a server serving only the v3 toggle endpoints is no longer supported.
• The reasons — no longer OpenFeature's Reason values. A server-resolved flag reports the service's own reason, a client-side match reports Matched rule '<name>'., no match reports Did not match any rules. Anything branching on Reason.TARGETING_MATCH changes silently, with no compile error.

The one decision worth your attention

refactor: flatten the v4 package into the provider package is a pure move, green on its own, and the rest of the branch sits on top of it.

The switch needs the evaluator, in the provider package, to call ServerSideEvaluation.evaluate(). Package access is not hierarchical, so a v4 sub-package would mean making that type and EvaluationResponse public — permanently, since OctopusProvider keeps its fully-qualified name and so the parent→v4 call outlives BMBB-780. With v4 now the only contract, the sub-package has served its purpose. Everything stays package-private, the public API is unchanged, and #51's duplicated rollout hash collapses back to one implementation.

The five fix: commits after the switch each came from a review of this branch, and each carries its own test — null entries and null bodies no longer cost the whole response, a null flag key answers FLAG_NOT_FOUND as v3 did, a ParseError logs its slug, and warn-once is provider-scoped, bounded and locale-independent.

One defect deliberately left in

A property of the wrong JSON type anywhere in the response still fails the whole manifest: it breaks while the response is being read, so it never reaches the per-flag reporting that contains a missing property. Tracked as BMBB-788 and deferred, so .NET and Java stay in step rather than this branch becoming the one place it is fixed — hence the revert: commit. The fix, with tests, is parked on #54.

Scope

BMBB-749 is here because it cannot be split off: the specification bump replaces its fixtures and a submodule has one pointer, so bumping first leaves v4 fixtures against a v3 provider — 80 failures, which I hit while separating the commits — and switching first leaves v4 code against deleted fixtures. .NET adopted the fixtures inside its own switch PR for the same reason.

Left to the tickets that own them, mirroring .NET's #96 → #99: BMBB-780 for the unused v3 types, still present and marked TODO(BMBB-780), and BMBB-755 for .NET's #97 renames (BMBB-715 looks like a duplicate of it).

Tests

461 pass, 0 failures, including all 83 specification tests (up from 41 — the v4 fixture set is larger) and MalformedEvaluationTests at 23 shapes. Public API confirmed unchanged via javap — still OctopusProvider, OctopusConfiguration and ProductMetadata.

🤖 Generated with Claude Code