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 sets of process (Linux only), user, and group IDs for filtering
connections from peer processes over IPC transport.  If all of the
filter sets are empty, every connection is accepted.  Otherwise,
credentials for a connecting process are checked against the filter sets
and the connection is only accepted if a match is found.

This commit is part of LIBZMQ-568 and only adds the filter sets and
implements the filter in the IPC accept method.  The interface for
adding IDs to filter sets are included in a separate commit.

IPC accept filtering is supported only on Linux and OS X.

This reverts commit bfd472f9.

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.

These were exposed to users, but have subsequently been removed as
sockopts. They are currently only being used by ZAP, so I've moved it to
a simpl function call (actually it's only used in one case even in that,
so there may be a further simplification possible there).

The use of binary for CURVE keys is painful; you cannot easily copy
these in e.g. email, or use them directly in source code. There are
various encoding possibilities. Base16 and Base64 are not optimal.
Ascii85 is not safe for source (it generates quotes and escapes).

So, I've designed a new Base85 encoding, Z85, which is safe to use
in code and elsewhere, and I've modified libzmq to use this where
it also uses binary keys (in get/setsockopt).

Very simply, if you use a 32-byte value, it's Base256 (binary),
and if you use a 40-byte value, it's Base85 (Z85).

I've put the Z85 codec into z85_codec.hpp, it's not elegant C++
but it is minimal and it works. Feel free to rewrap as a real class
if this annoys you.

- ZMQ_CURVE_PUBLICKEY for clients and servers
- ZMQ_CURVE_SECRETKEY for clients
- ZMQ_CURVE_SERVERKEY for clients
- ZMQ_CURVE_SERVER for servers
- added tools/curve_keygen.c as example
- updated man pages

- we need to switch to PLAIN according to options.mechanism
- we need to catch case when both peers are as-server (or neither is)
- and to use username/password from options, for client

* ZMQ_PLAIN_SERVER, ZMQ_PLAIN_USERNAME, ZMQ_PLAIN_PASSWORD options
* Man page changes to zmq_setsockopt and zmq_getsockopt
* Man pages for ZMQ_NULL, ZMQ_PLAIN, and ZMQ_CURVE
* Test program test_security

Copyrights had become ads for Sustrik's corporate sponsors, going against the original
agreement to share copyrights with the community (that agreement was: one line stating
iMatix copyright + one reference to AUTHORS file). The proliferation of corporate ads
is also unfair to the many individual authors. I've removed ALL corporate title from
the source files so the copyright statements can now be centralized in AUTHORS and
source files can be properly updated on an annual basis.

    - Created a new option ZMQ_ROUTER_RAW_SOCK
    - Added new raw_encoder and raw_decoder to receive and send messages in raw form to remote client
    - Added test case file tests/test_raw_sock.cpp

    o To create a raw router sock set the ZMQ_ROUTER_RAW_SOCK option
    o ZMQ_MSGMORE flag is ignored for non-id messages
    o To terminate a remote connection send id message followed by zero length data message

Fixes #415.

This patch, salvaged from a trainwreck accidental merge earlier, adds a
new sockopt, ZMQ_DELAY_ATTACH_ON_CONNECT which prevents a end point
being available to push messages to until it has fully connected, making
connect work more like bind. This also applies to reconnecting sockets,
which may cause message loss of in-queue messages, so it is sensible to
use this in conjunction with a low HWM and potentially an alternative
acknowledgement path.

Notes on most of the individual commits can be found the repository log.

Revert "After speaking with Ben Gray and the discussion on the mailing list, this is an attempt to create a sockopt to allow connecting pipes to not immediately be available for traffic. The problem is in a PUSH to many PULL situation, where there is a connect to a PULL which is not there. This connect will immediately create a pipe (unlike bind), and traffic will be load balanced to that pipe. This means if there is a persistently unavailable end point then the traffic will queue until HWM is hit, and older messages will be lost."

This reverts commit fe3fb419.

After speaking with Ben Gray and the discussion on the mailing list, this is an attempt to create a sockopt to allow connecting pipes to not immediately be available for traffic. The problem is in a PUSH to many PULL situation, where there is a connect to a PULL which is not there. This connect will immediately create a pipe (unlike bind), and traffic will be load balanced to that pipe. This means if there is a persistently unavailable end point then the traffic will queue until HWM is hit, and older messages will be lost.

This patch adds a sockopt ZMQ_DELAY_ATTACH_ON_CONNECT, which if set to 1 will attempt to preempt this behavior. It does this by extending the use of the session_base to include in the outbound as well as the inbound pipe, and only associates the pipe with the socket once it receives the connected callback via a process_attach message. This works, and a test has been added to show so, but may introduce unexpected complications. The shutdown logic in this class has become marginally more awkward because of this, requiring the session to serve as the sink for both pipes if shutdown occurs with a still-connecting pipe in place. It is also possible there could be issues around flushing the messages, but as I could not directly think how to create such an issue I have not written any code with regards to that.

The documentation has been updated to reflect the change, but please do check over the code and test and review.

Rename type zmq_monitor_fn -> zmq_monitor for a more natural callback definition API (zmq_monitor type, monitor.function callback)

Assign arbitrary number of filters that will be applied for each new TCP transport
connection on a listening socket.
If no filters applied, then TCP transport allows connections from any ip.
If at least one filter is applied then new connection source ip should be matched.
To clear all filters call zmq_setsockopt(socket, ZMQ_TCP_ACCEPT_FILTER, NULL, 0).
Filter is a null-terminated string with ipv6 or ipv4 CIDR.

For example:
localhost
127.0.0.1
mail.ru/24
::1
::1/128
3ffe:1::
3ffe:1::/56

Returns -1 if the filter couldn't be assigned(format error or ipv6 filter with ZMQ_IPV4ONLY set)

P.S.
The only thing that worries me is that I had to re-enable 'default assign by reference constructor/operator'
for 'tcp_address_t' (and for my inherited class tcp_address_mask_t) to store it in std::vector in 'options_t'...

currently not fully cross-platform
work on linux
possibly work in *bsd
and could be enhanced to work on windows

* Implemented new ctx API (_new, _destroy, _get, _set)
* Removed 'typesafe' macros from zmq.h
* Added support for MAX_SOCKETS (was tied into change for #337)
* Created new man pages