[PBI] SSE Event Emitter for API

[cjlapao]

Description

We need to create a new DevOps "Event Emitter" that will allow clients to subscribe to the events DevOps will emit as a service.
This will be used later on by for example the Orchestrator to subscribe to events from each client host and update the state of its vms/hosts depending on this. This PBI is for the ground work to allow any of this to happen.

What will we need?

• We will need to implement the emitter using the SSE technology see.
• We will need a channel system that we can issue messages to a global inbox or a client specific inbox
• We will need to have a retry connection system
• We will need a ping/pong for connectivity and health checks
• We will need to implement a robust logs
• We will need to implement the rest API endpoints for communication
• We will need to have easy to use functions from that service to send messages from anywhere in the DevOps
• We need to have multiple inboxes for different types of message the client can subscribe so they receive what they need
• We do not need to implement any messages of yet this will be done in a later stage

Event Message

For the Event Message we need to have something similar to this, we may add more

{
  "id": "0000-4f3e-0000-0000-000000000000",
  "type": "VM_STATE_CHANGED",
  "inbox": "pdfm",
  "timestamp": "2023-10-05T12:00:00Z",
  "message": "The virtual machine has changed state.",
  "body": {
    "previous_state": "running",
    "current_state": "stopped",
    "vm_id": "vm-123456"
  }
}

Go does not have to my knowledge any client for SSE so we will potentially need to create our own or check if there is any open source that we can use

User Story

As a user I want to be able to monitor in real time the messages DevOps service is issuing
As a developer I want to be able to easily send messages to the clients with what is updated

Acceptance Criteria

• We have a SSE service that can be consumed by any other DevOps Service
• We can initialize it only with API and Orchestrator mode
• We have unit tests covering this new functionality with 80% coverage
• We have easy to use functions for other services to push these notifications to clients
• We can target a client or all clients with our push notifications

Definition of Done

• Code implemented following best practices.
• Unit tests written and passing.
• Code reviewed and approved.
• Merged into the main branch.
• Documentation updated (if applicable).
• Deployed to staging/production environment.

Assumptions and Constraints

No response

Dependencies

No response

Additional Notes

No response