Solution: check for availability in CMake and autoconf before using it

Solution: Don't unlink file on close

File may not belong to the socket at that point.

Solution: extracted common base class curve_mechanism_base_t

Solution: Move ZAP tests to own file test_security_zap.cpp, move common code to testutil_security.hpp

Solution: created a zap_client_t class, extracted first function send_zap_request from curve_server_t

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: remove temporarily until proper message limits have been
implemented, then a more granular test case can be added without
such high requirements which are problematic in embedded environment,
build systems, VMs and CI systems

Solution: in project.gyp, define _WINSOCK_DEPRECATED_NO_WARNINGS

Solution: override in project.gyp, for Linux and OS/X.

Gyp needs its own platform.hpp; there is no way to delete this
file automatically.

Solution: copy gyp's platform.hpp into src, so that things build
properly no matter what the starting state. If you build with gyp
and then try to build using autotools' makefile, you'll get an
error from the platform.hpp.

Solution: add .gitignore in builds/gyp

Solution: raise to 16K

There were numerous small issues with test cases:

- some lacked the right source file header
- some were not portable at all
- some were using internal libzmq APIs (headers)

Solution: fixed and cleaned up.

Solution: offer a build.bat to help the user.

Solution: it's a lot of work to define the tests in project.gyp
so I did this using gsl to generate the JSON, from a small XML
list of the test cases.

To keep this, and the hundreds of .mk files, away from the root
directory, I've moved the gyp files into builds/gyp, where you
would run them.

It all seems to work now. Next up, OS/X and Windows :)

This is rather insane since the code knows well enough what systems
support if_nametoindex. I blame this on over-use of autotools early
in libzmq's days.

Anyhow, this breaks gyp builds on OS/X.

Solution: add ZMQ_HAVE_IFADDRS to build/gyp/platform.hpp for OS/X.

Solution: add necessary macros into builds/gyp/platform.hpp

Work for Linux now, other platforms to test.

I'm adding gyp support so that we can easily pull in libzmq
and other C/C++ projects into gyp packages, especially via
node-gyp.

Solution: add gyp definition

This works only for Windows, OS/X, and Linux. We set a single
macro in project.gyp according to the system, and the rest is
done in builds/gyp/platform.hpp. The values in that file are
not dynamic. Your mileage will vary.