ROX-36856: retire Compliance 1.0 REST and gRPC endpoints - #23399

Description

First backend cut of Compliance 1.0 removal (ROX-36856). This PR removes the externally reachable Compliance 1.0 API surface; the ~271 files under central/compliance/ are left in place, now unreachable, and are deleted in follow-ups once the compiler can prove it is safe.

Removed

• ComplianceService and ComplianceManagementService are no longer registered in servicesToRegister(). Because pkg/grpc.APIService carries both RegisterServiceServer and RegisterServiceHandler, this removes the gRPC services and their grpc-gateway REST equivalents under /v1/compliance/* in one step. Callers now get Unimplemented / HTTP 501.
• The /api/compliance/export/csv custom route.
• qa-tests-backend's ComplianceTest (@Tag("BAT")), which exercises only the removed v1 API and would otherwise fail against this change, plus the service/object classes that became orphaned with it.

Kept, deliberately: /api/splunk/ta/compliance now returns 410 Gone

The acceptance criteria require existing Splunk TA Compliance feed configurations to fail closed. Alternatives considered:

🔔 This 410 is a contract with external TA users and is the one decision in this PR that wants explicit sign-off. Happy to change the status code or wording if the Splunk TA owner prefers something else.

The handler also drops its datastore.DataStore parameter. That is load-bearing beyond the 410: it severs central/splunk's compile-time import of central/compliance, which is what allows that tree to be deleted independently in a later PR.

Not in this PR: GraphQL resolvers (~1,177 lines + 449 refs in generated code, coupled to proto removal), the .proto definitions, the central/compliance/ tree itself, and the five Compliance 1.0 Postgres tables (GORM AutoMigrate never drops, so those need an explicit migration). resources.Compliance is intentionally untouched — it is shared with Compliance v2 and is a customer-visible permission name.

This PR has no file overlap with #23360 and can merge in either order.

Customer impact worth explicit review: Compliance Operator results stop reaching Splunk

This surfaced from a review question about the ocp4-cis-node-master / MachineConfigResults fixtures in the deleted test. They are not Compliance v2 data, but tracing them found a real consequence.

Compliance Operator results reach this feed through the pre-v2 bridge:

central/complianceoperator/manager          (NOT .../v2/ -- manager_impl.go:16)
  -> GetMachineConfigs(clusterID)            (manager_impl.go:123)
  -> framework.NewComplianceDomain
  -> collect_results.go:234 -> MachineConfigResults
  -> storage.ComplianceRunResults (v1 tables)
  -> /api/splunk/ta/compliance

So a customer running the Compliance Operator today, with the TA Compliance modular input enabled, loses that data in Splunk when this merges. They cannot migrate, because there is no v2 Splunk feed (RFE-9120 / RFE-6372, out of scope here). The Compliance Operator itself and Compliance v2 in-product are unaffected; only the Splunk delivery path goes away.

The CHANGELOG now splits the API removal from the feed retirement and states plainly that no Splunk replacement exists, rather than implying v2 covers it. Flagging here so this is a conscious call by the Splunk TA owner and release-notes reviewer, not a surprise.

For the record on the original question: Compliance v2 is fully independent — grepping central/complianceoperator/v2/ for imports of central/compliance/ returns zero hits, and v2 has its own storage (checkresults, scans, profiles, ...). Separately, a _test.go file is only ever compiled into its own package's test binary, so no other package could have depended on the deleted test regardless.

User-facing documentation

• CHANGELOG.md is updated OR update is not needed
• documentation PR is created and is linked above OR is not needed

Downstream docs are tracked by ROX-36856's own Documentation & Release Notes acceptance criterion and will follow separately. CHANGELOG entries are included here under "Removed Features" — one for the API removal, one for the Splunk feed retirement and its Compliance Operator consequence.

Testing and quality

• the change is production ready: the change is GA, or otherwise the functionality is gated by a feature flag
• CI results are inspected

Automated testing

• added unit tests
• added e2e tests
• added regression tests
• added compatibility tests
• modified existing tests

Added a unit test asserting the Splunk endpoint returns 410 with the removal message. This is deliberately a test rather than a bare stub: the fail-closed behavior is an external contract, so a later "tidy-up" to 404 should break the build.

How I validated my change

• go build ./... — pass
• go vet ./... — pass (type-checks _test.go files, so the new test compiles)
• go test -tags test ./central/... — 296 packages pass, 1 fails. The failure is central/clusters/zip panicking in init() via testutils.MustBeInTest; it reproduces identically on clean master at c4b073da25, so it is pre-existing and unrelated.
• gofmt — clean
• Grepped for dangling references to everything removed: no remaining hits for /api/compliance/export/csv, complianceHandlers, complianceManagerService, CSV_COLUMN_MAPPING, objects.Control, CsvRow, or ComplianceServiceGrpc outside the tree scheduled for later deletion.

Gap I want to be explicit about: I could not compile the Groovy locally — generateProto fails because scanner/api/v1/{component,note}.proto are absent from qa-tests-backend/src/main/proto, so no Java proto classes are generated and every io.stackrox.proto.* import fails. This reproduces on clean master (199 unresolved-proto errors before my change, 181 after; the delta is exactly the imports in the files I deleted, and zero errors name any file I touched). Confidence in the Groovy deletions therefore rests on grep rather than a compiler. CI is the real check here.

🤖 Co-Generated with [Claude Code]