Relicense statement for Juraj Oršulić

Always include ZMQSourceRunChecks.cmake

Solution: fix issue introduced by #3270

Problem: gabm didn't signalise his consent to relicense libzmq

* ZMQ_DGRAM: flip more flag after successful send

In the dgram socket we have a flag that indicates the next expected message type to ensure that always a pair of "address" + "body" messages gets sent. The first one MUST have the sendmore flag, the second MUST NOT.

In case the message does not get sent because of HWM full, then the function returns EAGAIN as it should. But unfortunately the next expected message type-flag gets flipped as well. When the socket_base::send function now tries to resend the message, it became the wrong message type... If you don't stop sending pairs of messages here (like me) then the next message that gets through will be of the wrong type, which in turn crashes the udp_engine function as described in #3268

Problem: Compilation with strict AARCH64 compilers is broken

This patch fixes an issue that occurs on 64-bit architetures under
strict compiler rules. The code initially checked that the received
size stored in 'uint64_t' was not bigger than the max value of a
'size_t' variable, which is legitimate on 32-bit architectures where
'size_t' variables are stored on 32 bits. On 64-bit architectures,
this test no longer makes sense since 'uint64_t' and 'size_t' types
have the same size. The issue is fixed by ignoring this portion
of code when built for arm64.

[ISSUE 2488] Updates the zmq_msg_send doc

Solution: Add more information to the doc specifying that MAX_INT is the maximum
possible return value.

Problem: test_connect_delay_tipc randomly fails

Solution: use a monitor to wait for a disconnect instead of a sleep,
and retry to send a message until it fails since the state machine
might be delayed due to the I/O thread being pre-empted on busy
systems.
Also set a receive timeout to avoid random hangs.

Fixes #3124

Problem: have to ask manually for relicensing grant

Solution: add note in PR template

Problem: INSTALL refers to deprecated VS build instructions

Solution: remove the reference

Remove race condition from XPUB/SUB test in test_blocking()

Fix for test_hwm_pubsub

Problem: test_proxy_hwm randomly fails

Solution: allow for a range between the minimum and maximum expected.
With 2 queues, that's between 20 and 40 messages depending on the
scheduling of the 3 threads involved.

Solution: use atomics to avoid issues on non-x86 architectures

Improve test reliability by: a) using XPUB in place of PUB to ensure …

Improve test reliability by: a) using XPUB in place of PUB to ensure we start publishing only after 1st subscriber has joined; b) accept both 2*HWM, 3*HWM and 4*HWM as TX/RX count of messages

add relicensing grant

Add new HWM tests and more detailed documentation

fix static build with libatomic

Create RELICENSE/FabriceFontaine.md
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>

Commit 2ec5a33f added support to link
with -latomic if needed however using LDFLAGS doesn't work when
statically linking because LDFLAGS is added before LIBS

Detection of atomic fails with:

configure:23230: /accts/mlweber1/instance-2/output/host/bin/sparc-linux-g++ -o conftest -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -Os   -static -static -pedantic -Werror -Wall -D_GNU_SOURCE -D_REENTRANT -D_THREAD_SAFE -Wno-long-long -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -static -latomic conftest.cpp -lrt -lpthread -lstdc++ >&5
/tmp/ccgrvVTg.o: In function `main':
conftest.cpp:(.text.startup+0x10): undefined reference to `__atomic_fetch_add_4'
collect2: error: ld returned 1 exit status

So use LIBS instead of LDFLAGS

Fixes:
 - http://autobuild.buildroot.net/results/c471d6b1061a8516f7772735e471db68a32965aaSigned-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>

RELICENSE: Christoph Schulz

CMake cleanup

- Lowercase all commands
- Unify indent to 2 spaces
- Remove spaces around brackets
- Remove repitition of condition in else(...) and endif(...)

Note: (re-)running CMake did not change the content of the generated files