[Engine] Adopt Ray as orchestration backend

[Superskyyy]

I've been experimenting with the pipeline using native multiprocessing and Redis Streams/RQ recently, and it quickly becomes messy when we spawn many processes.

So I'm evaluating Ray as the backend engine to orchestrate the streaming processing jobs while supporting batch learning that anomaly detection might utilize. By far, it looks promising.

The main benefit of Ray to us includes:

1. Worker management (Redis Streams will be only for IN/OUT data queue, no longer a task queue),
2. It's much lighter than Spark/Flink.
3. Autoscaling.
4. It has a UI to monitor some critical system metrics.

@Liangshumin @Fengrui-Liu FYI, there'll be some changes to the existing designs that I communicated over chat, please pay attention to the algorithm training part as Ray offers many out-of-the-box ML features.

• For logs (clustering)
• For metrics

[Superskyyy]

Things I've tested:

1. Pure multiprocessing with native queue - very low throughout.

2. Redis streams + multiprocessing - fast but complex, it cannot be scaled or reduced easily.

3. Redis task queue - high Redis overhead, weird to do stream processing.

4. Current plan for Log data:

Source (OAP) ->
N*gRPC(Ingestors) ->
In Stream(Redis)->
Ray Actor(Stream Consumers) -> Maskers(Preprocessors) ->
Ready Stream(Redis)->
ML(Learners) ->
Out Stream(Redis)->
Ray Actor (Exporters) ->
Destination (OAP)

[Superskyyy]

I'll complete a prototype to showcase the flow over this weekend.

[Superskyyy]

POC: #23

[Superskyyy]

Closing in favor of movement to Flink. New PoC is implemented.