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

Solution: mention this in the documentation

Solution: add them to the event monitor manpage

Solution: add a note pointing out that when new events are added the
ZMQ_EVENT_ALL mask will start returning them, so applications that
can't handle that transparently should not use it and instead pick
only the event types they want.
Creating a new event type and having monitors with ZMQ_EVENT_ALL
return them will not be considered a backward incompatible change
even though the flow of events will change.

Solution: move it there, add it to src/zmq_draft.h and clarify in the
documentation and in the NEWS file that this option is not yet stable

Solution: add paragraphs to zmq_get/setsockopt man pages

Solution: add manpage

Solution: mention it in zmq_ctx_get manpage

This addresses #2169.

Solution: Fix it.

The effect can be seen on http://api.zeromq.org/4-2:zmq-getsockopt at
options ZMQ_USE_FD and ZMQ_RATE.

Solution: fix length of squiggly line under option title

Solution: fix it.

The documentation first states that the ZMQ_SNDMORE flag is ignored on
data frames. Then it states that omitting the ZMQ_SNDMORE flag has
consequences. The example HTTP server code further muddies the situation
with a similar comment.

The implementation of ZMQ_STREAM only accepts two-part messages.
The first part is an identity frame while the second and last part is
the data frame.

As with any multipart message, all parts except the last need the
ZMQ_SNDMORE flag. The second and last part would normally omit the
ZMQ_SNDMORE flag to mark the end of the multipart message.

However, the ZMQ_STREAM implementation ignores the ZMQ_SNDMORE flag on
the data frame rather than requiring that it be omitted. The latter
behaviour would have been more consistent with the other ZeroMQ
sockets.

Solution:
- Update formatting and remove redundant parts from ZMQ_PROBE_ROUTER,
ZMQ_USE_FD, ZMQ_TCP_MAXRT, ZMQ_TCP_TOS
- Only cosmetic changes to the content
- These changes already merged on api.zeromq.org by me

It says that ZMQ_SERVER never blocks; whereas it does block on
sending to a client whose pipe is full.

Solution: fix it.

Problem: when using ZMQ_REQ_RELAXED + ZMQ_REQ_CORRELATE and two 'send' are
executed in a row and no server is available at the time of the sends,
then the internal request_id used to identify messages gets corrupted and
the two messages end up with the same request_id. The correlation no
longer works in that case and you may end up with the wrong message.

Solution: make a copy of the request_id instance member before sending it
down the pipe.

Solution: add the document files to the MAN_DOC and MAN_HTML targets
in doc/Makefile.am only if BUILD_DOC and INSTALL_MAN are set,
otherwise leave the targets empty to avoid errors in make distcheck.

And I'm on a reasonably sized laptop. I think allocating INT_MAX
memory is dangerous in a test case.

Solution: expose this as a context option. I've used ZMQ_MAX_MSGSZ
and documented it and implemented the API. However I don't know how
to get the parent context for a socket, so the code in zmq.cpp is
still unfinished.

These options are confusing and redundant. Their names suggest
they apply to the tcp:// transport, yet they are used for all
stream protocols. The methods zmq::set_tcp_receive_buffer and
zmq::set_tcp_send_buffer don't use these values at all, they use
ZMQ_SNDBUF and ZMQ_RCVBUF.

Solution: merge these new options into ZMQ_SNDBUF and ZMQ_RCVBUF.

This means defaulting these two options to 8192, and removing the
new options. We now have ZMQ_SNDBUF and ZMQ_RCVBUF being used both
for TCP socket control, and for input/output buffering.

Note: the default for SNDBUF and RCVBUF are otherwise 4096.

The proper name is ZMQ_THREAD_SAFE

Solution: fix in the documentation.

This option has a few issues. The name is long and clumsy. The
functonality is not smooth: one must set both this and
ZMQ_XPUB_VERBOSE at the same time, or things will break mysteriously.

Solution: rename to ZMQ_XPUB_VERBOSER and make an atomic option.

That is, implicitly does ZMQ_XPUB_VERBOSE.