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.

Problem: tweetnacl on *nix use of /dev/urandom is not thread safe

Solution: if available use the getrandom function as it doesn't
require any synchronization, state or cleanup

Solution: open with O_CLOEXEC if available or set FD_CLOEXEC if not

Solution: add a crypto [de-]initialiser, refcounted and serialised
through critical sections.
This is necessary as utility APIs such as zmq_curve_keypair also
call into the sodium/tweetnacl libraries and need the initialisation
outside of the zmq context.
Also the libsodium documentation explicitly says that sodium_init
must not be called concurrently from multiple threads, which could
have happened until now. Also the randombytes_close function does
not appear to be thread safe either.
This change guarantees that the library is initialised only once at
any given time across the whole program.
Fixes #2632

Solution: fix it

Suppress C4324 (VC++2017)

'zmq::command_t': structure was padded due to alignment specifier
https://msdn.microsoft.com/en-us/library/92fdk6xx.aspx

Don't try to set IPV6_V6ONLY on OpenBSD

Solution: skip setsockopt call resulting in EINVAL

RELICENSE: minrk

configure.ac: allow user to disable libunwind discovery via --disable-libunwind

on ia64 architecture libunwind comes with gcc. Unfortunately
libunwind is not directly usable as-is and fails at link time:

```
    ia64-unknown-linux-gnu-g++ -o perf/.libs/local_lat perf/local_lat.o src/.libs/libzmq.so -lsodium -lrt -lpthread -ldl
    src/.libs/libzmq.so: undefined reference to `_ULia64_step'
```

The change adds --{enable,disable}-libunwind flag to control
automatic dependency. The default is unchanged: use if available.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Problem: adapt, clarify docs ZMQ_ROUTER_MANDATORY

Solution:

* Document the new behaviour when generating 'ZMQ_POLLOUT' events
  for ZMQ_ROUTER sockets with 'ZMQ_ROUTER_MANDATORY' set to `1`
* Add clarifications for 'ZMQ_ROUTER' socket when
  'ZMQ_ROUTER_MANDATORY' is set to `1`

Fix ROUTER's xhas_out() in MANDATORY mode

Before this commit, xhas_out() was returning true regardless. This
was correct before the ZMQ_ROUTER_MANDATORY flag as introduced.
However, ZMQ_POLLOUT.

With this commit, _if_ ZMQ_ROUTER_MANDATORY is set, xhas_out() will
return false if ALL peer's outgoing pipes are full.

There is an outstanding high-level design question:

If ZMQ_ROUTER_MANDATORY is set, and zmq_poll() waits for ZMQ_POLLOUT
events, zmq_poll() will immediately wake up if only 1 pipe has
room to send, regardless of the peer, creating a busy loop of
zmq_poll() wake-up, zmq_send() (EAGAIN). There is no way for
the application to selectively wait for ZMQ_POLLOUT for specific
peer(s), which seems somehow necessary in ZMQ_ROUTER_MANDATORY.

This discussion will be addressed in a separate issue.
Signed-off-by: Marc Sune <marc@voltanet.io>
Signed-off-by: Fredi Raspall <fredi@voltanet.io>

Problem: CURVE server (connect) fails when client rebinds

Solution: if a CURVE server is using zmq_connect, the same session
will be used for any client "reconnect" (actual binds). This is
acceptable, so do not assert if zap_pipe already exists during the
handshake, but simply reuse it.
Fixes #2608

RELICENSE: Matt Connolly

Refs #2376

Problem: When using print_backtrace() on Linux with libunwind, printout of stack traces from multiple threads are interleaved. Solution: added static mutex to serialize printing of stack traces.

Problem: intermittent memory leak for req/rep send/recv. #2602 Solution: memory leak fixed.

Problem: When using print_backtrace() on Linux with libunwind, printout of stack traces from multiple threads are interleaved. Solution: added static mutex to serialize printing of stack traces.

Update zmq.txt

Fixed minor typo.

Problem: XPUB_MANUAL subscriptions not removed on peer term

Solution: remove the pipe from the real trie when a peer disconnects.
Also add a unit test that exercises the behaviour by reconnecting
a different socket and sending a message that matches.
Fixes #2601 and introduced by #2042

Solution: fix unit test to bind after setting the option.

Problems: ZAP can be set up incorrectly, CURVE and GSSAPI can be used only with ZAP

Problem: cannot cross-compile with Mingw-w64

Solution: we can use 'CMAKE_SYSTEM_VERSION' instead of
'${CMAKE_SYSTEM_VERSION}' for the 'if' clauses.

CMake fails to evaluate condition when CMAKE_SYSTEM_VERSION is
empty, which can happen with a default installation of Mingw-w64
in Linux.

Solution: use lower case ws2_32.lib to enable cross compilation
from platforms with case-sensitive filesystems.

When cross compiling the tests with Mingw-w64, CMake cannot
locate Ws2_32.lib

Solution: do not fail if ZAP is not enabled.
GSSAPI already provides authentication and can be used separately,
so it is a valid use case.

Solution: revert change that made ZAP mandatory.
The "Stonehouse" pattern, where CURVE is used only for encryption and
without authentication, is a valid use case so we should still
support it.
Also restore CURVE testing in the test_heartbeat.

Fixes #2594

Solution: if inproc://zeromq.zap.01 exists, which means ZAP is
enabled, abort immediately if it cannot be used (eg: out of memory)
or it is configured incorrectly (eg: wrong socket type).
Otherwise authentication failures will simply be ignored and
unauthorised peers will be allowed to slip in.

fix bug: #2592 dish client does not resend subscriptions to radio server after radio server restart

problem: for zmq radio/dish pattern, if the radio process restarts, the dish will not resend subscriptions to radio. And the result is that the dish will never receive any more messages.

solution: in session_base_t::reconnect (), take ZMQ_DISH into consideration when invoking hiccup method.