MacOS/Clang complain due to presence of -Wnewline-eof in CZMQ.

environment variables.

Users who need e.g. zmq_curve_keypair() have to remember to include
zmq_utils.h, which is counter-intuitive. The whole library should be
represented by a single include file.

Solution: merge all contents of zmq_utils.h into zmq.h, and deprecate
zmq_utils.h. Existing apps can continue unchanged. New apps can ignore
zmq_utils.h completely.

This is still raw and experimental.
To connect through a SOCKS proxy, set ZMQ_SOCKS_PROXY socket option on
socket before issuing a connect call, e.g.:

    zmq_setsockopt (s, ZMQ_SOCKS_PROXY,
        "127.0.0.1:22222", strlen ("127.0.0.1:22222"));
    zmq_connect (s, "tcp://127.0.0.1:5555");

Known limitations:
- only SOCKS version 5 supported
- authentication not supported
- new option is still undocumented

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.

This reverts commit 5e0facda.

Provides control of race windows and logging for some of the interesting transitions.

Added modifiers reflect the following properties:
- zmq_msg_gets () does not mutate property parameter
- zmq_msg_gets () returns a pointer to memory the caller should not
  modify

Specifically:

* zmq_event_t should not be used internally in libzmq, it was
  meant to be an outward facing structure.

* In 4.x, zmq_event_t does not correspond to monitor events, so
  I removed the structure entirely.

* man page for zmq_socket_monitor is incomplete and the example
  code was particularly nasty.

* test_monitor.cpp needed rewriting, it was not clean.

Fixes #967

As per suggestion by Pieter Hintjens. Also update wording in
zmq_ctx_set manual a bit.

This reverts commit 9ae6a91f.

This reverts commit bc7441f5.

The new options allows querying the maximum allowed number of sockets.
This is system dependent and cannot be encoded in the include file as a
preprocessor macro: for ZMQ_USE_SELECT, this depends on the FD_SETSIZE
macro at time of library compilation, not at time of include file use.

- renamed to ZMQ_CONNECT_RID
- fixed whitespace malformating around previous patch
- renamamed next_peer_id to next_rid in preparation for
  larger rename of IDENTITY to ROUTING_ID

Note: ZMQ_CONNECT_RID has no test case and no entry in the man
page, as yet.

Fixed compile issue with missing member of socket_base.  Changed ZMQ_NEXT_IDENTITY to ZMQ_NEXT_CONNECT_PEER_ID.

Fixed case where ZMQ_NEXT_CONNECT_PEER_ID is used in ROUTER, and ROUTER does not read the identity message from the connected pipe.

Both STREAM and ROUTER sockets suffer from a naming problem on outbound connections. While these connections can be created, they can't be immediately used. Traffic must be received before it can be sent. This prevents practical, minimal usage of STREAM or ROUTER as a true N fan in/out socket.

This change simply provides the user with a socket option that sets a user defined name of the next outbound connection:

zmq_setsockopt(routerSock,ZMQ_NEXT_IDENTITY,"myname",6);
if(0 > zmq_connect(routerSock,"tcp://127.0.0.1:1234")) return 1;
ret = zmq_send(routerSock,"myname",6,ZMQ_SNDMORE);
zmq_send(routerSock,b.mem,b.used,0);

In this example, the socket is immediately given the name "myname", and is capable of immediately sending traffic.

This approach is more effective in three ways:
1) It prevents all sorts of malicious peer naming attacks that can cause undefined behavior in existing ROUTER connections. (Two connections are made that both transmit the same name to the ROUTER, the ROUTER behavior is undefined)
2) It allows immediate control of connections made to external parties for STREAM sockets. Something that is not possible right now. Before an outbound connection had no name for STREAM or ROUTER sockets because outbound connections cannot be sent to without first receiving traffic.
3) It is simpler and more general than expecting two ROUTER sockets to handshake on assigned connection names. Plus it allows inline sending to new connections on ROUTER.

Also moved the fd field from message content to message itself

This patch allows client applications to retrieve the remote endpoint from a message that originated from a tcp socket

- This seems redundant; is there a use case for NOT providing
  the IPC credentials to the ZAP authenticator?

- More, why is IPC authentication done via libzmq instead of ZAP?
  Is it because we're missing the transport type on the ZAP request?

Another take on LIBZMQ-568 to allow filtering IPC connections, this time
using ZAP.  This change is backward compatible.  If the
ZMQ_ZAP_IPC_CREDS option is set, the user, group, and process IDs of the
peer process are appended to the address (separated by colons) of a ZAP
request; otherwise, nothing changes.  See LIBZMQ-568 and zmq_setsockopt
documentation for more information.