[2SP] CMW: Port everything that can be to native 0qm subscriptions

[ivan-cukic]

Check if we're using old subscription mechanisms in OpenCMW. Wherever possible, remove use of SUBSCRIBE/UNSUBSCRIBE via router socket (mdp://) by zmq's native PUB/SUB mechanism. Document in case there are any limitations to PUB/SUB that require the old mechanism to be kept. Adjust unit tests.

For the REST backend, there is an opened PR that needs updating
#277

[frankosterfeld]

I've found a limitation when using the native 0mq PUB/SUB mechanism between clients and a broker.

Let's assume three clients A, B, C subscribe to A: /colors, B: /colors?red, C: /colors?green&red. (The params being alphabetically sorted is enforced by the openCMW API).

The worker publishes a notification with topic /colors?contentType=application%2Fjson&green&red, which matches all three subscriptions from A, B, C. The broker can skip publishing it with /colors, as the 0mq subscription message ensures that a message to /colors?red or /colors?green&red is also received by A.

But that's the problem: The broker must publish the message to both /colors?red and colors?green&red, to ensure that both B and C receive the message.

But as A's subscription to /colors matches both, A will receive the message twice.

I'm reading that RADIO/DISH uses exact matching, I can test that. It's in draft state though.

One could also hack around the prefix matching but appending some reserved "end token" to each subscription to prevent prefix matching to ever succeed. (/colors/$END$, /colors?red$END$ or similar)