- 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?

- put into alphabetical order
- there was no consistency in previous ordering

Minor layout fix

Whitespace fix

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.

Adds ZMQ_IPC_ACCEPT_FILTER_{PID,UID,GID} socket options to add processs,
user, and group IDs to the IPC filter sets. Fixes LIBZMQ-568.

Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>

Documentation examples for zmq_msg_get and zmq_msg_more functions have an
incorrect call to zmq_msg_close function - with 'zmq_msg_t' as a parameter
despite 'zmq_msg_t *' is required, so it is impossible to compile these
examples properly.

Also for zmq_msg_get example - declaration of zmq_msg_t variable is added
(like it is done in other examples).

* Added new man page for this
* Added test case, in tests/test_security_curve.cpp
* Noted in zmq_utils.h that these methods are documented

* ZMQ_REQ_STRICT was negative option (default 1) which goes against
  the standard, where defaults are zero. I renamed this to
  ZMQ_REQ_RELAXED.

* ZMQ_REQ_REQUEST_IDS felt clumsy and describes the technical solution
  rather than the problem/requirement. I changed to ZMQ_REQ_CORRELATE
  which seems more explicit.

* Removed redundant Z85 code and include files from project
* Simplified use of headers in test cases (now they all just use testutil.hpp)
* Export zmq_z85_encode() and zmq_z85_decode() in API
* Added man pages for these two functions

On ZMQ_CURVE_xxxKEY fetches, would return 41 bytes into caller's 40-byte
buffer. Now these fetches only return 41 bytes if the caller explicitly
provides a 41-byte buffer (i.e. the option size is 41).

* This is passed to the ZAP handler in the 'domain' field

* If not set, or empty, then NULL security does not call the ZAP handler

* This resolves the phantom ZAP request syndrome seen with sockets where
  security was never intended (e.g. in test cases)

* This means if you install a ZAP handler, it will not get any requests
  for new connections until you take some explicit action, which can be
  setting a username/password for PLAIN, a key for CURVE, or the domain
  for NULL.

It defaults to enabled. Switch it off to be able to send a new message
before the previous reply has been received.