We do not use 'get' for getters.

Solution: rename to zmq_msg_routing_id () for public API.

Solution: Move the macros to a private header.

Solution: Convert to spaces and remove trailing whitespace in these files.

Fixes not receiving unsubscription messages in XPUB socket with
ZMQ_XPUB_VERBOSE and using a XSUB-XPUB proxy in front.

This adds two modifications:

- It adds a new flag, ZMQ_XPUB_VERBOSE_UNSUBSCRIBE, to enable verbose
  unsubscription messages, necessary when using a XSUB/XPUB proxy.

- It adds a boolean switch to zmq::mtrie_t::rm () to control if the
  callback is invoked every time or only in the last removal. Necessary
  when a pipe is terminated and the verbose mode for unsubscriptions is
  enabled.

This commit adds ZMTP connection heartbeats described in
http://rfc.zeromq.org/spec:37/ZMTP.

Of course people still "can" distributed the sources under the
LGPLv3. However we provide COPYING.LESSER with additional grants.

Solution: specify these grants in the header of each source file.

should be backported probably

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

Solution: update for 2015

Fixes #1320

Increasing it would have at least two benefits -

* More messages would be 'VSM' messages, so it would reduce allocation
overhead a bit.
* Remove any chance of false sharing of things that are, by design,
pushed by value onto a ypipe_t<msg_t> which is shared between two threads.

The only downside I see is slightly increased memory consumption on memory
constrained applications.

- Full discussion of this rationale is part of issue #1295

Revert "linking fd to pipe identity via socket option"

This reverts commit fe3e8c5c.

Conflicts:
	include/zmq.h
	src/pipe.hpp
	src/session_base.cpp

Firstly, only a few types are defined, leaving it hard for higher layers
to complete the set. Secondly, the code incorrectly tries to use ifndef
to avoid re-defining typedefs, which does not work in C.

Solution: define all types, unconditionally for all MSVC compilers.
Additionally, define ZMQ_DEFINED_STDINT that tells higher layers that we
already defined these integer types.

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.

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);

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.