Solution: set errno to EINVAL when tcp:// endpoint is invalid (was just
leaving errno to previous value).

Rationale: In a real-time environment it is sometime mandatory to tune
threads priority and scheduling policy. This is required by our users
who mixes real-time and server threads within
the same process. It's not planned to support this on non-pthread
platforms (e.g. Windows).

This syntax is undocumented and has no known meaning. It was in libzmq
since 3.x.

Solution: remove this code.

Since https://github.com/zeromq/libzmq/commit/350a1a, TCP addresses
get resolved asynchronously, so zmq_connect no longer returned an
error on incorrect addresses.

This is troublesome since we rely on some error checking to catch
blatant errors.

Solution add some upfront syntax checking that catches at least the
obvious kinds of errors (invalid characters, wrong or missing port
number).

This is still raw and experimental.
To connect through a SOCKS proxy, set ZMQ_SOCKS_PROXY socket option on
socket before issuing a connect call, e.g.:

    zmq_setsockopt (s, ZMQ_SOCKS_PROXY,
        "127.0.0.1:22222", strlen ("127.0.0.1:22222"));
    zmq_connect (s, "tcp://127.0.0.1:5555");

Known limitations:
- only SOCKS version 5 supported
- authentication not supported
- new option is still undocumented

As libzmq is compiled with optional transports and security mechanisms,
there is no clean way for applications to determine what capabilities
are actually available in a given libzmq instance.

Solution: provide an API specifically for capability reporting. The
zmq_has () method is meant to be open ended. It accepts a string so
that we can add arbitrary capabilities without breaking existing
applications.

zmq.h also defines ZMQ_HAS_CAPABILITIES when this method is provided.

Solution: use same approach as for libsodium/CURVE, i.e. return EINVAL
if the library isn't present when libzmq builds, and the application
still tries to use these options in zmq_getsockopt/setsockopt.

The example is applications passing invalid arguments to a socket option
and then failing to check the return code. The results can be very hard
to diagnose. Here are some threads that show the pain this causes:

* https://github.com/zeromq/zyre/issues/179
* http://lists.zeromq.org/pipermail/zeromq-dev/2014-June/026388.html

One common argument is that a library should never assert, and should
pass errors back to the calling application. The counter argument is
that when an application is broken enough to pass garbage to libzmq,
it cannot be trusted to handle the resulting errors properly. Empirical
evidence from CZMQ, where we systematically assert on bad arguments, is
that this militant approach makes applications more, not less, robust.

I don't see any valid use cases for returning errors on bad arguments,
with one exception: zmq_setsockopt can be used to probe whether libzmq
was e.g. built with CURVE security. I'd argue that it's nasty to use a
side effect like this. If apps need to probe how libzmq was built, this
should be done explicitly, and for ALL build options, not just CURVE.

There are/were no libzmq test cases that check the return code for an
invalid option.

For now I've enabled militant assertions using --with-militant at
configure time. However I'd like to make this the default setting.

Well, not gibberish, but 2^31 on Linux, which is useless. The code
should probably use getrlimit on Linux and other calls depending on
the system. For now I've set the ceiling at 64K.

In de9eef30, the error number assigned to WSAENOTSOCK was EFAULT, but
zmq.cpp:919 expects an ENOTSOCK in this case.

(accidentially used my preferred style)

As mentioned on the mailing list, Windows may return WSAEADDRINUSE when binding
(reconnecting) to a port. Added this to the handled error codes as Pieter
suggested.

The list of error codes is taken from zmq::wsa_error_no(). Most of the
new WSA error codes result in EFAULT, but some return a more specific
value (even EAGAIN).

Fixes #1071

- limit visibility of pending_connection_t
- add const qualifiers

- add const modifier to address parameter of event generating functions

Applications that use ZMQ_IDENTITY can be trapped by the artificial
restriction on not using a binary zero as first byte. It's specially
nasty on random generated identities, e.g. UUIDs, as the chance of a
binary zero is low, so it will pass 255 out of 256 times.

Solution: remove the restriction.