receive_event: Make it optionally semi-nonblocking

[nuclearcat]

Right now receive_event is blocking, and even on receiving keep alive it stay inside its own busy loop, which makes impossible to implement proper scheduling, watchdogs, health monitoring.
We make optional parameter, where on keep alive message, (sent each 45 sec by kernelci-api) it will return None. We keep backward compatible defaults, as lot of code is not expecting None in return.

[pawiecz]

LGTM (functionally)

Argument semantics is non-obvious to me - shouldn't the event receiving loop be broken if the keep_alive value is False (this would require setting defaults to True and reversing loop condition)?

[JenySadadia]

The below code snippet in receive_event makes sure that it keeps on listening to events after BEEP is received:

if event.data == 'BEEP':
    continue

Instead of this workaround, I'd suggest we should check why receive_event loop blocks.

[nuclearcat]

The below code snippet in receive_event makes sure that it keeps on listening to events after BEEP is received:

if event.data == 'BEEP':
    continue

Instead of this workaround, I'd suggest we should check why receive_event loop blocks.
While I understand it looks like a workaround, making receive_event non-blocking on keep-alive messages is the intended fix here.

The core issue is that the busy loop prevents other critical tasks from running. A deeper change to the event-receiving logic would be much more complex and might have unintended side effects. This approach gives us the scheduling flexibility we need while maintaining backward compatibility.
This PR is intended as a tactical fix for the scheduling problems, which hit us hard and caused builds outage for several days.
For more fundamental changes i am planning to redesign event system in near future.