Windows zbeacon ZSYS_INTERFACE support and correct default adapter
Default adapter was set to INADDR_ANY, which does not work on Windows when calling getnameinfo.
zbeacon windows interface string comparison fix
Merge pull request #548 from twhittock/win-interface

Windows zbeacon ZSYS_INTERFACE support and correct default adapter
Fix Windows zbeacon port
Problem: does not initialize system before running selftest

This fails on Windows. Solution: call zsys_init() at start of
selftest method.

Fixes #542.
Problem: zsys_file_mode did not return RW attributes on Windows

There was an #ifdef UTYPE_ANDROID in the middle of the Windows
section, which makes no sense.

Solution: remove the #ifdef.

Fixes #543
Problem: initialization sequence was wrong

The sequence has to be:

1. get environment variables, initialize mutex and create socket
   reference list.
2. allow caller to set io_threads, max_sockets
3. create context and then sockets

So bundling (1) and (3) together did not work. Now the context is
created lazily at first zsys_socket(), and the _set methods all call
zsys_init().
Various fixes

Fixes #545
Fixes #544

More work on extended test case for zgossip.
Cosmetic style fixes
Merge pull request #549 from twhittock/win-interface

Fix Windows zbeacon port
Added gossip tester
Updated man pages
Merge pull request #546 from hintjens/master

Problem: does not initialize system before running selftest
Removed test_zgossip binary
Removed unused macros
Problem: zgossip fails with large swarms / set sizes

I've extended the test_zgossip tool to allow tests with larger swarms
and set sizes, and have tested swarms of up to 1,000 nodes and set sizes
of 8K or higher.

Two issues hit. One is system limits on file handles. On Linux this is
1024 by default, and the hard upper limit seems to be 4096. Each node
in a swarm needs 4 file handles, and we use 8 for infrastructure, so
1024 handles lets us run 254 nodes, the default for the test case.

Second issue is pipe overflow with large set sizes. There are two places
this hits. First, the DEALER socket that each peer uses to talk to a
remote. When this is full, the node simply blocks and when enough nodes
block, the test case deadlocks. Second, the ROUTER socket that each peer
uses to talk to its client peers. When this is full, the node drops
outgoing PUBLISH messages, and the test case never completes.

The solution in both cases is to set an infinite HWM. The risk is that
when/if applications use very large set sizes, they will cause memory
overflow. The soltion, if this problem ever hits, is to use a CBFC model
on tuple publishing.
Merge pull request #551 from hintjens/master

Finishing test_zgossip test case
Minor documentation changes
Merge pull request #552 from hintjens/master

Minor documentation changes
Updated zgossip documentation