The zero copy decoding strategy implemented for 4.2.0 can lead to a large
increase of main memory usage in some cases (I have seen one program go up to
40G from 10G after upgrading from 4.1.4). This commit adds a new option to
contexts, called ZMQ_ZERO_COPY_RECV, which allows one to switch to the old
decoding strategy.

Solultion: clarify that notifications for unique subs/unsubs are always
passed, and these option only affect the behaviour for duplicated ones.

Problem: Wrong linger default value

Solution: correct documentation

Solution: add them

Change ZMQ_THREAD_AFFINITY to ZMQ_THREAD_AFFINITY_CPU_ADD/ZMQ_THREAD_AFFINITY_CPU_REMOVE. Avoid prefix thread names when no prefix was set.

Solution: provide correct description

Fixes #2789

* Clarify usage of zmq_close

Solution: mention that the STATISTICS command returns a message with 8
frames

Solution: fix it

Solution: add a section in zmq_ctx_set's manpage

Solution: mention that it is used on Linux when SCHED_OTHER is selected

Solution: add ZMQ_ZAP_ENFORCE_DOMAIN to hide backward incompatible
change and make it disabled by default.
In a future release that breaks API compatibility we can then switch
the default to enabled in order to achieve full RFC compatibility.

Fixes #2762

Solution: use "routing_id" instead

Solution: Replaced by "routing id"

Solution: change docs to refer to "Routing id"

Solution: fix documentation

Solution: use "routing_id" instead

Solution: Replaced by "routing id"

Solution: change docs to refer to "Routing id"

Solution: relaxed assertion to accept 10% of the SNDHWM, and updated documentation accordingly

Solution: as discussed, remove the deprecation notices, as many users
expressed the need for multi-part support.
Fixes #2699

  state of ZMQ_EVENT_HANDSHAKE_FAILED_* events

Solution: update documentation

group being a `char *` is logically a text type, which needs an encoding.

Declare in the API that groups shall be UTF8-encoded,
matching the `zmq_msg_gets` API, which is the other user-facing `char *` API,
which has the same definition.

This allows bindings to provide text-type APIs,
which they cannot do if arbitrary bytes are allowed

Solution: add documentation

Solution: Remove from documentation

Linux now supports Virtual Routing and Forwarding (VRF) as per:

https://www.kernel.org/doc/Documentation/networking/vrf.txt

In order for an application to bind or connect to a socket with an
address in a VRF, they need to first bind the socket to the VRF device:

    setsockopt(sd, SOL_SOCKET, SO_BINDTODEVICE, dev, strlen(dev)+1);

Note "dev" is the VRF device, eg. VRF "blue", rather than an interface
enslaved to the VRF.

Add a new socket option, ZMQ_BINDTODEVICE, to bind a socket to a device.
In general, if a socket is bound to a device, eg. an interface, only
packets received from that particular device are processed by the socket.

If device is a VRF device, then subsequent binds/connects to that socket
use addresses in the VRF routing table.

Solution:

* Document the new behaviour when generating 'ZMQ_POLLOUT' events
  for ZMQ_ROUTER sockets with 'ZMQ_ROUTER_MANDATORY' set to `1`
* Add clarifications for 'ZMQ_ROUTER' socket when
  'ZMQ_ROUTER_MANDATORY' is set to `1`

Fixed minor typo.

Problem: GSSAPI NAMETYPE options were not documented in man
pages for zmq_getsockopt() and zmq_setsockopt().

Solution: add new options to these manual pages.

Problem: zmq_gssapi.7 was not mentioned in doc/Makefile.am

Solution: add man page to MAN7 in doc/Makefile.am

Problem: new GSSAPI socket options are not documented.

Solution: add PRINCIPAL NAMES section to zmq_gssapi.7

Problem: the ZMQ_GSSAPI_PRINCIPAL socket option is described
as mandatory in the zmq_gssapi(7) manual page.  In fact it
is optional.

Solution: Describe ZMQ_GSSAPI_PRINCIPAL as optional.
If unspecified, default credentials are used.

Solution: fix it

Solution: fix it