Add Status and List APIs for participants

[Adibla]

This PR introduces a new Status API that allows programmatic querying of participant provisioning status, eliminating the need to manually inspect Kubernetes logs. In order to resolve that i've added two new REST endpoints that provide status information:

1. Get Participant Status

GET /api/v1/resources/:participantName/status

Returns detailed status including:

• Overall provisioning status (READY, PROVISIONING, DEGRADED, etc.)
• Individual component status (controlplane, dataplane, identityhub, postgres)
• Recent Kubernetes events
• Replica counts and health

2. List All Participants

GET /api/v1/resources?status=READY&page=1&limit=10

Returns paginated list of all participants with:

• Status filtering
• Pagination support
• response with pagination headers

Examples

Get Participant Status

curl http://localhost:9999/api/v1/resources/aruba07/status

Response:

{
  "participantName": "aruba07",
  "status": "READY",
  "lastUpdated": "2025-01-15T10:30:00Z",
  "components": {
    "controlplane": {
      "status": "Running",
      "ready": true,
      "replicas": {"desired": 1, "current": 1, "ready": 1}
    },
    "dataplane": {
      "status": "Running", 
      "ready": true,
      "replicas": {"desired": 1, "current": 1, "ready": 1}
    }
  },
  "message": "All components are running and ready",
  "events": [
    {
      "timestamp": "2025-01-15T10:25:00Z",
      "type": "Info",
      "message": "Deployment controlplane ready"
    }
  ]
}

List Participants with Pagination

curl 'http://localhost:9999/api/v1/resources?status=READY&page=1&limit=5'

Response Headers:

X-Total: 25
X-Page: 1
X-Limit: 5

Response Body:

[
  {
    "participantName": "aruba01",
    "status": "READY",
    "lastUpdated": "2025-01-15T10:30:00Z"
  },
  {
    "participantName": "aruba02", 
    "status": "READY",
    "lastUpdated": "2025-01-15T10:25:00Z"
  }
]

For simplicity, an in-memory cache has been implemented to avoid overloading the cluster with unnecessary requests. In a production environment or other contexts, an external cache solution (such as Redis) would be more appropriate for scalability and persistence across service restarts.

Thanks.