Problem: zmq_bind IPv4 fallback still tries IPv6

Solution: in the Windows-specific ifdef in tcp_listener set_address,
check for error and set errno only after the IPv4 fallback has failed
too, to avoid setting errno when the socket creation succeeds through
the fallback.

Solution: if opening an IPv6 TCP socket fails because IPv6 is not
available, try to open an IPv4 socket instead when creating and
connecting a TCP endpoint.

Solution: if opening an IPv6 TCP socket fails because IPv6 is not
available, try to open an IPv4 socket instead when creating and
binding a TCP endpoint.

Problem: including recent "zmq_utils.h" crashes gcc -pedantic jobs

Problem: Recent deprecation of the "zmq_utils.h" header file caused pedantic compilations (including czmq) to fail because non-portable #warning is used.
Solution: Limit the deprecation warnings to compilers known or assumed to support the "#pragma message" (GCC, MSVC, CLANG) and wrap with GCC directives to not treat these warnings as errors on paranoid builds.

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

Solution: fix it.

Fix NetBSD thread scheduling problem.

Defining thread priority for SCHED_OTHER is implementation defined.
Some platforms like NetBSD cannot reassign it as they are dynamic.

<http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_getschedparam.html>

Credit goes to <kamil@netbsd.org> and <riastradh@netbsd.org> for finding this
solution.

Fixed ZMQ_REQ_CORRELATE (see pull request #1730)

Problem: Since pull request #1730 was merged, protocol for REQ socket is
checked at the session level and this check does not take into account
the possibility of a request_id being part of the message. Thus the option
ZMQ_REQ_CORRELATE would no longer work.
This is now fixed: the possiblity of a 4 bytes integer being present
before the delimiter frame is taken into account (whether or not this
breaks the REQ/REP RFC is another issue).

Fixes #1419 segfault when using a XSUB/XPUB proxy.

Ref. https://github.com/zeromq/libzmq/issues/1419

Windows XP compatability fixes

A Visual Studio build from master (commit id: dac5b45d) using the v140_xp toolset yields a binary that is not XP compatible.

Two libraries contain exports that cannot be found:
 -  IPHLPAPI.DLL : if_nametoindex
 - KERNEL32.DLL : InitializeConditionVariable

The latter export is already dealt with in the file './src/condition_variable.hpp'; however this requires setting the _WIN32_WINNT pre-processor definition.
I am not experienced enough to figure a work around for the 'if_nametoindex' method, so I have created a new pre-processor definition 'ZMQ_HAVE_WINDOWS_TARGET_XP' and removed the calling of the function with the limitation that these builds cannot handle a IPv6 address with an adapter name.

To make it easier for people targeting XP with an MSVC build I have modified the MSBuild property file to add/modify the pre-processor definitions if they are building using a XP targeting tool set; such as v140_xp.

Improve MSVC builds

* Added a new .gitignore file for excluding Visual Studio build output any popular plug-in generated content. (This was copied from the GitHub project https://github.com/github/gitignore).
* Removed the basic ignore settings from the root folder in favour of more precision within the subfolder's .gitignore file
* Added the new VC compiler's experimental Intellisense database file

All the older (vs2010 -> vs2013) projects had copies of the Visual Studio 2015 MSBuild applied to them when running the 'configure.bat' batch file. Any modifications to a property sheet was not applied to the other Visual Studio versions' projects unless the batch file was re-executed.

* Modified the older projects to reference the Visual Studio 2015 property sheets so changes are immediately applied
* Removed the batch file copy steps (which left the repository very dirty after execution)

Tweaks to building libzmq

I changed this to ZMQ_USE_SODIUM to be consistent with other
configuration options (especially ZMQ_USE_TWEETNACL).

Solution: fix it.

Tweaks to building libzmq

Solution: update them.

Solution: use ZMQ_USE_LIBSODIUM to match ZMQ_USE_TWEETNACL

Problem: build fails when CURVE security is disabled

Solution: use proper preprocessor macro

Problem: CURVE mechanism is unusable with chroot()

libsodium calls abort() when /dev/urandom can't be found
even if one creates ZeroMQ context before calling chroot()[1].

This happens because crypto gets initialized on handshake,
and at that moment the process is already chroot'ed.

Solution: initialize cryptographic libraries in ctx

randombytes_close() is already there in the destructor.

[1] https://download.libsodium.org/doc/usage/index.html

Update zmq_utils.h

Previous change broke MSVC b/c MSVC doesn't support #warning

zeromq-4.1.4/src/tcp_address.cpp : fix relaxed use of sizeof() without parenthesis

Fixed issue #1695 (ZMQ_REQ_CORRELATE)

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.

Add Valgrind make target and CI run

Solution: pass built-root when calling coveralls, to help it find the
right path to the source code.

Solution: run Travis CI in newer Trusty (14.04 LTS) release.

Solution: do not run test_fork if --enable-valgrind is set. Note that
later versions of Valgrind (3.11) not yet available in all
distributions fix this problem, so we might revert in the future.