ZMQ_INVERT_MATCHING reverses the PUB/SUB prefix matching. The subscription
list becomes a rejection list. The PUB socket sends messages to all
connected (X)SUB sockets that do not have any matching subscription.

Whenever the option is used on a PUB/XPUB socket, any connecting SUB
sockets must also set it or they will reject everything the publisher
sends them. XSUB sockets are unaffected because they do not filter out
incoming messages.

Symptom is that ZMQ_STREAM sockets in 4.1.0 and 4.1.1 generate zero
sized messages on each new connection, unlike 4.0.x which did not do
this.

Person who made this commit also changed test cases so that contract
breakage did not show. Same person was later banned for persistently
poor form in CZMQ contributions.

Solution: enable connect notifications on ZMQ_STREAM sockets using a
new ZMQ_STREAM_NOTIFY setting. By default, socket does not deliver
notifications, and behaves as in 4.0.x.

Fixes #1316

Allows non-C/C++ based clients easy access to the peer's IP address via
zmq_msg_gets(&msg, "Peer-Address") instead of zmq_msg_get(&msg, ZMQ_SRCFD)
followed by calls to getpeername and getnameinfo

zmq_atomic_counter_dec returned a 'bool' value, yet this isn't
defined by standard, so causes compile errors in upstream code.

Solution: return an int that can be safely converted to bool if
needed by bindings.

Solution: as libzmq already provides this across all platforms,
expose an atomic counter API. I've not wrapped atomic pointers,
though someone who needs this may want to do so.

There is zero benefit to this, and some confusion due to the special
case nature of this man page.

Solution: delete the zmq_epgm man page.

Solution: set defaults back to infinity, and add new context
option, ZMQ_BLOCKY that the user can set to false to get a
less surprising behavior on context termination. Eg.

    zmq_ctx_set (ctx, ZMQ_BLOCKY, false);

Regression in #1248 can cause lost messages at exit.

behavior -> behaviour
initialize -> initialse
initialization -> initialisation

Solution: use a sane value, e.g. 2 seconds

Fixes #1247

Solution: document this with a clear warning. It would be
nicer perhaps to change the default LINGER to e.g. a few
seconds. However this could break existing applications.

This commit adds a ZMQ_POLLPRI flag that maps to poll()'s POLLPRI
flag.
This flags does nothing for OMQ sockets. It's only useful for raw
file descriptor (be it socket or file).
This flag does nothing if poll() is not the underlying polling
function. So it is Linux only.

Solution: document the limit of 113 chars including ipc://. We might
fix this in libzmq by shortening an over-long IPC pathname into a
unique string; so long as this is done consistently in bind and in
connect, it will save applications from weird failures when they
use external data to generate IPC pathnames.

Solution: change setsockopts on printable keys to expect 41, nor 40
bytes. Code still accepts 40 bytes for compatibility, and copies the
key to a well-terminated string before using it.

Fixes #1148

clarifies that these are text fields,
and removes ambiguity about how to create proper
text object from stored bytes.

Solution: fix Makefile.am

As per Richard Sharpe on zeromq-dev.

As libzmq is compiled with optional transports and security mechanisms,
there is no clean way for applications to determine what capabilities
are actually available in a given libzmq instance.

Solution: provide an API specifically for capability reporting. The
zmq_has () method is meant to be open ended. It accepts a string so
that we can add arbitrary capabilities without breaking existing
applications.

zmq.h also defines ZMQ_HAS_CAPABILITIES when this method is provided.

Applications that use ZMQ_IDENTITY can be trapped by the artificial
restriction on not using a binary zero as first byte. It's specially
nasty on random generated identities, e.g. UUIDs, as the chance of a
binary zero is low, so it will pass 255 out of 256 times.

Solution: remove the restriction.