Solution: fix it

Problem: stale bot didn't parse labels correctly

Solution: quote the labels with a space, upstream documentation
(not displayed on the Github page) suggests this should finally work

Problem: stale issues linger on Github

Solution: enable Stable Bot to automatically mark an issue as stale
after 365 days of inactivity and close it after further 56 days.

Issues marked with the following labels are excluded:

 - Help Request
 - Feature Request
 - Problem reproduced
 - Critical

Problem: NEWS still out of date

Solution: mention all relevant bug fixes, features and changes

Problems: wrong version and outdated NEWS

Some changes for CMakeLists.txt:

- MacOS version requires CMake version 3.0.2 (because of policy CMP0042)
- Add option to build instrumented binaries with Address Sanitizer
- Add option to select compiler intrinsics for atomic ops
- Only build docs on request (saves build time)

Solution: partially list changes since 4.2.5. Not yet complete.

Solution: bump back from 4.3.1 to 4.3.0

Problem: new radix tree implementation is experimental

Solution: use it only for DRAFT builds for now, to leave it time to be
tested and stabilised.

Problem: potentially large memory footprint of trie as number of subscriptions increases (issue #1400)

Solution: add it

subscriptions increases

Solution: use a radix tree instead of a trie to store subscriptions

Problem: Use of pipe_t after free in zmq::socket_base_t::term_endpoint(). Issue #3245.

Solution: When pipe_t is freed (terminated) remove it from _endpoints member of zmq::socket_base_t. Resolves issue #3245.

Add support for UDP multicast ttl (ZMQ_MULTICAST_HOPS)

Solution: add relicense agreement

Solution: add support for ZMQ_MULTICAST_HOPS (IP_MULTICAST_TTL)

Relicense statement for Hpsaturn

fix for android building

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