refactor: SpiceDB test

[silvi-t]

Description

• Refactored SpiceDB integration to support multiple dynamically deployed instances instead of relying on a single pre-configured external instance

Changes

Refactoring

• testsuite/spicedb/spicedb.py: Complete refactor of SpiceDB integration
  • Replaced SpiceDBService with SpiceDB (Backend) and SpiceDBClient classes
  • Implemented custom HTTP client using httpx for SpiceDB HTTP API (/v1/schema/write, /v1/relationships/write, /v1/permissions/check)
  • Added Kubernetes deployment and service management as a Backend
  • Implemented lazy-initialized client with proper type annotations
  • Routes test suite traffic through Gateway via HTTPRoute instead of LoadBalancer
  • Maintains gRPC connectivity for Authorino using internal cluster DNS

Configuration

• config/settings.yaml: Added spicedb.image configuration with default image quay.io/authzed/spicedb:latest
• config/settings.local.yaml.tpl: Updated template to use image instead of url and password
• testsuite/config/__init__.py: Removed validators for spicedb.url and spicedb.password as they are no longer needed

Verification steps

# Test with Kuadrant
poetry run pytest -vv testsuite/tests/singlecluster/authorino/authorization/spicedb/test_spicedb.py

# Test with Authorino standalone
poetry run pytest -vv --standalone testsuite/tests/singlecluster/authorino/authorization/spicedb/test_spicedb.py

Follow-up
After merging, step 2 from #770 needs to be completed: Remove the SpiceDB instance from tools.

[azgabur]

If the purpose of this PR is just to allow parallel runs of the same test I think only modification of fixtures schema_config and relationship_config was needed or maybe some other places. Currently (on main) the configs uses static names for all fields which I presume would override each other. Not sure how the spiceDB handles writes of the same schemas. Did you try making the names of the schemas unique between runs?

[silvi-t]

If the purpose of this PR is just to allow parallel runs of the same test I think only modification of fixtures schema_config and relationship_config was needed or maybe some other places. Currently (on main) the configs uses static names for all fields which I presume would override each other. Not sure how the spiceDB handles writes of the same schemas. Did you try making the names of the schemas unique between runs?

The problem is that the schema in SpiceDB only overwrites itself, and using unique names does not solve this problem. Therefore, you cannot have multiple schemas in a single SpiceDB instance. That is why we want to create a single instance for each test.

[silvi-t]

I've added a commit to handle SpiceDB connection issues related to LoadBalancer provisioning and I would like to hear your thoughts on the solution @azgabur, @averevki:
Context:
The LoadBalancer external IP in our OpenStack environment may be provisioned and active but not routable from the test environment. This is an infrastructure limitation that occurs sporadically:

• On clusters with rhos-01: LoadBalancer becomes reachable after approximately 5 minutes
• On clusters with rhos-d: LoadBalancer IP never becomes accessible when this issue occurs
• The issue is not consistent and only happens occasionally

The retry logic gives the LoadBalancer time to become accessible on rhos-01 clusters, and if it remains unreachable after retries, the test is skipped with a clear explanation rather than producing a false test failure.

[azgabur]

Loadbalancer problems on Openstack are indeed infrastructure problem. If SpiceDB is not used in multicluster testing maybe using local service url would suffice?
Also changing from spicedb in tools to deploying instances at runtime would make the problem worse in my opinion as you "roll the dice" multiple times instead of once at kuadrant deploy in which case it can be fixed by re-creating the loadbalancer service and from that point it will keep working. If it gets stuck at runtime you need to only re-run the test and hope the spicedb loadbalancer will work that time.
At least my opinion.

[silvi-t]

Loadbalancer problems on Openstack are indeed infrastructure problem. If SpiceDB is not used in multicluster testing maybe using local service url would suffice? Also changing from spicedb in tools to deploying instances at runtime would make the problem worse in my opinion as you "roll the dice" multiple times instead of once at kuadrant deploy in which case it can be fixed by re-creating the loadbalancer service and from that point it will keep working. If it gets stuck at runtime you need to only re-run the test and hope the spicedb loadbalancer will work that time. At least my opinion.

@azgabur I've taken your suggestion to use local service URLs instead of relying on LoadBalancer IPs.

I've changed the approach to route to SpiceDB through an HTTPRoute via the Gateway. This eliminates the LoadBalancer reliability issues on OpenStack entirely.

The reason I had to switch to an HTTP client is that the official authzed Python client only supports gRPC, and HTTPRoute cannot route gRPC traffic in OpenShift. So I implemented a custom HTTP client using httpx that
calls SpiceDB's HTTP API endpoints like /v1/schema/write and /v1/relationships/write.

Regarding deploying instances at runtime versus using SpiceDB in tools - I actually think having one instance per test is better in this case. SpiceDB doesn't support running multiple schemas in a single instance, which
makes parallel testing (if we add more tests in the future) impossible if we share one SpiceDB instance. Each test needs its own isolated schema, so deploying separate instances allows us to run tests in parallel without
schema conflicts.

[averevki]

LGTM

[azgabur]

Not sure why the library was removed in favor of direct http client but it works and I dont mind.