Feat/flexible topology config

[Transcendental-Programmer]

Description

This PR implements flexible topology configuration for SliceConfig, enabling hub-spoke, custom connectivity patterns, and restricted topologies to replace the hardcoded full-mesh model.

What changed:

1. API types (apis/controller/v1alpha1/sliceconfig_types.go):

   • Added TopologyConfig with 3 topology types: full-mesh (default), custom, restricted
   • Added ConnectivityMatrix for explicit source→target definitions (custom mode)
   • Added ForbiddenEdges to exclude specific cluster pairs (restricted mode)
   • All fields optional with backward-compatible defaults

2. Service layer (service/topology_service.go):

   • New TopologyService with dependency injection pattern
   • resolveTopologyPairs() - main entry point returning gateway pairs
   • resolveFullMeshTopology() - creates n*(n-1)/2 bidirectional pairs
   • resolveCustomTopology() - processes connectivity matrix entries
   • resolveRestrictedTopology() - full-mesh minus forbidden edges
   • filterForbiddenPairs() - bidirectional filtering (blocks both A→B and B→A)
   • 100% unit test coverage (67 tests)

3. Validation (service/slice_config_webhook_validation.go):

   • Inline validation helpers for topology config fields
   • validateTopologyConfig() - orchestrates all topology validation
   • validateCustomTopology() - ensures all clusters in matrix exist in spec.clusters
   • validateRestrictedTopology() - validates forbidden edge clusters
   • validateForbiddenEdges() - checks source/target cluster validity
   • Returns proper field.ErrorList for API server integration

4. Gateway integration (service/worker_slice_gateway_service.go):

   • Refactored CreateMinimumWorkerSliceGateways() to use topology service
   • Changed from nested loop (O(n²)) to topology-aware pair processing
   • Gateway creation now respects topology configuration
   • Maintains bidirectional VPN tunnel semantics (2 gateway objects per pair)

5. Integration tests (controllers/controller/sliceconfig_controller_test.go):

   • 7 topology test cases with envtest
   • Full-mesh: verifies 1 pair → 2 gateways (2 clusters), 3 pairs → 6 gateways (3 clusters)
   • Custom: verifies matrix respected (1 pair specified → 2 gateways)
   • Restricted: verifies forbidden edges excluded (3 clusters, forbid 1→3 → 4 gateways remain)
   • Dynamic updates: verifies topology changes trigger gateway reconciliation
   • Default behavior: nil topology config → full-mesh

6. CRD updates (config/crd/bases/controller.kubeslice.io_sliceconfigs.yaml):

   • Extended OpenAPI schema with topology fields
   • Enum validation for topologyType
   • All topology fields marked optional

Architecture highlights:

• Bidirectional filtering: Forbidding A→B also blocks B→A due to symmetric gateway naming ({A,B} set creates both slice-A-B and slice-B-A)
• Gateway pairs: Each directional pair creates 2 gateway objects (server + client) for bidirectional VPN tunnel
• Stateless topology service: Pure transformation (SliceConfig → []GatewayPair), no side effects
• Dependency injection: TopologyService wired in main.go and passed to gateway service

Backward compatibility:

SliceConfigs without topologyConfig default to full-mesh (maintains existing behavior). No breaking changes.

Fixes: #253

How Has This Been Tested?

Unit tests:

make test  # All 67 topology tests passing
go test ./service -run "Topology" -coverprofile=coverage.out
go tool cover -html=coverage.out  # 100% coverage for 11 topology functions

Integration tests:

make test  # envtest-based controller tests
# 7 topology integration tests verify gateway creation for all topology types

Manual verification in kind cluster:

• CRD applied with new topology fields
• Full-mesh topology: 3 clusters → 6 gateways created
• Custom topology: 1→2 specified → 2 gateways created
• Restricted topology: 3 clusters, forbid 1→3 → 4 gateways created
• Backward compatibility: SliceConfig without topology → full-mesh (2 gateways for 2 clusters)

Checklist:

• The title states what changed and related issue number
• Documentation: Inline code comments + kubebuilder markers
• Self-review performed
• Code commented (validation logic, gateway pair semantics)
• Unit tests: 67 tests, 100% coverage
• Integration tests: 7 envtest-based scenarios

Does this PR introduce a breaking change?

No. All topology fields are optional. Existing SliceConfigs continue to work with full-mesh default.

Add flexible topology configuration support to SliceConfig with full-mesh, custom, and restricted modes