Feature/metric proxy bindings

[Tim-Dieringer]

Added command to start ZMQ server, which listens for requests from Metric Proxy. Includes variable port, argument usage from the Proxy, MessagePack serialization/deserialization and uses either parallel execution for multiple metrics or normal execution for a single metric.
This is a complementary feature to https://github.com/A-Tarraf/proxy_v2/tree/feature_ftio and is related to Issue #13 .

[A-Tarraf]

Is this actually used, or do you use the prediction server already implemented in FTIO?

[Tim-Dieringer]

ftio/api/metric_proxy/proxy_zmq.py is a zmq server to specifically support what metric proxy needs, so it is used. It's probably possible to change proxy_zmq.py to rely on some of the already implemented functions instead of using a complete custom method but that would require refactoring.

[A-Tarraf]

No, this is fine. I was just wondering because we introduced a new class (prediction) and wanted to avoid dictionaries. But if there is no way to use the class, we can keep it this way. I would just suggest that you document these points alongside some instructions (e.g., call tree?) in a separate file for FTIO as described here: https://github.com/tuda-parallel/FTIO/blob/feature/pattern_change_detection/docs/students_contribute.md#-module-documentation-and-licensing. Also, maybe you can add some test cases so that we do not break these functionalities in the future with newer commits (https://github.com/tuda-parallel/FTIO/blob/feature/pattern_change_detection/docs/students_contribute.md#-module-documentation-and-licensing)