ZeroMQ read handler

[eqvinox]

this is "the other way around" compared to PR #522.
I believe this is far easier to integrate and have less conflicts / impact on other changes in our event loop.

@bingen can you check if this works for your code?

[NetDEF-CI]

Continous Integration Result: SUCCESSFUL

Congratulations, this patch passed basic tests

Tested-by: NetDEF / OpenSourceRouting.org CI System

CI System Testrun URL: https://ci1.netdef.org/browse/FRR-FRRPULLREQ-740/

This is a comment from an EXPERIMENTAL automated CI system.
For questions and feedback in regards to this CI system, please feel free to email
Martin Winter - mwinter (at) opensourcerouting.org.

[bingen]

I really like this approach and I agree is way better isolated so easier to integrate. The reason we modified thread.c was to replace standard select by zmq_poll, as we had some problems with selects. Sometimes select was detecting some "noise" in the fd that we had to filter. I understand that here you do a zmq_poll after the select (or nowadays a poll) and that should filter the noise too. I'll try it to confirm that it works.
The only problem I see is that we are using ROUTER-DEALER pattern, so the function you use to do zmq_recv wouldn't work for us, as we need to do something like this:

	ret = zmq_msg_init(&zdelim);
	ret = zmq_msg_init(&zmsg);

	ret = zmq_msg_recv(&zdelim, sock, flags);
	ret = zmq_msg_recv(&zmsg, sock,   flags);

If anybody is interested, have a look at this.
I guess one easy solution would be to be able to pass the function used as a callback for funcname_thread_add_read_write as a parameter for funcname_frrzmq_thread_read_msg. If this parameter comes NULL we may fall back to the standard one frrzmq_read_msg. This way we could pass a function of ours with that multiple receive explained above.

[eqvinox]

hmm... isn't that functionally the same as 2 receive calls? first an empty one, then the data?

[eqvinox]

discussed on slack => will change to 2 handlers, one doing no message receiving, the other receiving all parts of the message (however many there may be)

[eqvinox]

will put new version up

[pguibert6WIND]

this looks interesting.
so that REQ/REP and ROUTER/DEALER patterns will be supported.