RHCLOUD-44967: added health endpoints

[akoserwal]

PR Template:

Describe your changes

Interfaces

Following https://github.com/grpc/grpc/blob/master/doc/health-checking.md

gRPC — grpc.health.v1.Health

RPC	Description
Check(HealthCheckRequest)	Returns the current ServingStatus for a named service. Returns gRPC NOT_FOUND for unregistered service names.
Watch(HealthCheckRequest)	Opens a server-streaming RPC. Immediately sends the current status, then pushes an update each time the status changes.

Registered service names:

Service key	Maps to
"" (empty string)	Overall server liveness — always SERVING once the gRPC server is listening
envoy.service.auth.v3.Authorization	Envoy ext_authz service
parsec.v1.TokenExchangeService	OAuth 2.0 Token Exchange service
parsec.v1.JWKSService	JWKS endpoint service

HTTP

Endpoint	Method	Purpose	Response
/healthz/live	GET	Liveness probe	Always 200 {"status":"OK"}
/healthz/ready	GET	Readiness probe	200 {"status":"SERVING"} when all services are SERVING; 503 {"status":"NOT_SERVING","service":"<name>"} otherwise

Both HTTP handlers set Cache-Control: no-cache, no-store, must-revalidate to prevent stale responses through reverse proxies. Non-GET methods receive 405 Method Not Allowed.

How to test

gRPC — Overall Health (Liveness)

grpcurl -plaintext localhost:9090 grpc.health.v1.Health/Check

5. gRPC — Per-Service Health (Readiness)

# Check a specific service
grpcurl -plaintext -d '{"service": "parsec.v1.TokenExchangeService"}' \
  localhost:9066 grpc.health.v1.Health/Check

Ticket reference (if applicable)

Fixes #

Checklist

• Are the agreed upon acceptance criteria fulfilled?

• Was the 4-eye-principle applied? (async PR review, pairing, ensembling)

• Do your changes have passing automated tests and sufficient observability?

• Are the work steps you introduced repeatable by others, either through automation or documentation?

  • If automation is possible but not done due to other constraints, a ticket to the tech debt sprint is added
  • An SOP (Standard Operating Procedure) was created

• The Changes were automatically built, tested, and - if needed, behind a feature flag - deployed to our production environment. (Please check this when the new deployment is done and you could verify it.)

• Are the agreed upon coding/architectural practices applied?

• Are security needs fullfilled? (e.g. no internal URL)

• Is the corresponding Ticket in the right state? (should be on "review" now, put to done when this change made it to production)

• For changes to the public API / code dependencies: Was the whole team (or a sufficient amount of ppl) able to review?

hit by accident

[Rajagopalan-Ranganathan]

@alechenninger - for your eyes