DOC: unreliable sockpair@ on macOS

We discovered that the sockpair@ protocol is unreliable in macOS, this
is the same problem that we fixed in d7f6819. But it's not possible to
implement a acknowledgment once the socket are in non-blocking mode.

The problem was discovered in issue #3045.

Must be backported in every stable versions.

doc/configuration.txt

@@ -1514,6 +1514,11 @@ socket type and the transport method.
                the FD from the unix socket and uses it as if it were the FD
                of an accept(). Should be used carefully.
 
+               Bugs: This protocol is known to be unreliable on macOS because
+               of an issue in the macOS sendmsg(2) implementation. The
+               connection might not be accepted correctly.
+
+
 'unix@<path>'  following string is considered as a UNIX socket <path>. this
                prefix is useful to declare an UNIX socket path which don't
                start by slash '/'.

doc/management.txt

@@ -4380,6 +4380,11 @@ Example:
   case the full command ends at the end of line or semi-colon like any regular
   command.
 
+  Bugs: the sockpair@ protocol used to implement communication between the
+  master and the worker is known to not be reliable on macOS because of an
+  issue in the macOS sendmsg(2) implementation. A command might end up without
+  response because of that.
+
   Examples:
 
     $ socat /var/run/haproxy-master.sock readline
@@ -4446,6 +4451,11 @@ Example:
   command). In this case, the prompt mode of the master socket (interactive,
   prompt, timed) is propagated into the worker process.
 
+  Bugs: the sockpair@ protocol used to implement communication between the
+  master and the worker is known to not be reliable on macOS because of an
+  issue in the macOS sendmsg(2) implementation. A command might end up without
+  response because of that.
+
   Examples:
     # gracefully close connections and delete a server once idle (wait max 10s)
     $ socat -t 11 /var/run/haproxy-master.sock - <<< \