possible socket leak in xmem connection pool

As part of looking at CBSE-1659 we found (unrelated) issue in commit that went into 3.0.

Specifically this commit:

Author: Aliaksey Kandratsenka <alk@tut.by> 2014-04-08 13:37:00
Committer: Artem Stemkovski <artem@couchbase.com> 2014-04-09 19:42:21
Parent: ff523c145f8934732d56469bd99b9b0a817c857b (recognize flow control commands for purpose of debugging upr)
Child: 48cd37b51b42fb763f03ea3eb0b46e90410b8f17 (avoid spamming logs by xdcr_upr_streamer on crashes in better way)
Branches: master and many more (37)
Follows: 3.0.0r, local-2.5.1
Precedes: ZOO-BASE

don't crash connection pool when handling done from unknown pid

There's a tiny chance for connection pool to receive EXIT message and
die when xdcr is having frequent crashes (i.e. during
rebalance). That's relatively normal.

What is not normal is that newly started connection pool instance
would crash again when socket is returned back to it from unknown
process.

In order to fix it we now simply drop such requests (and sockets) on
the floor.

Change-Id: I5cfe87c88f8f7b497eb9c89e9846b0fb871c3b94
Reviewed-on: http://review.couchbase.org/35530
Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
Reviewed-by: Artem Stemkovski <artem@couchbase.com>

The issue is that sockets are not actually dropped on the floor but remain linked to pool process. Potentially accumulating and eventually exhausting list of ephemeral ports at kernel level.