We have seen examples of our memcached clients not timing out for several minutes on reads and/or writes in our Kubernetes environment under certain conditions occurring after node rebalancing and subsequent mecached pod rescheduling. This was despite us setting a very short (10ms) receive timeout in the client configuration.

After some digging, we realized that Socket.ReceiveTimeout only affects blocking receive calls. This is well-documented in the Socket.ReceiveTimeout docs, as well as the documentation for the underlying setsockopt documentation (emphasis mine):

SO_RCVTIMEO | DWORD | Sets the timeout, in milliseconds, for blocking receive calls.

This PR wraps calls to NetworkStream.ReadAsync in PooledSocket in a Task.WhenAny(readTask, timeoutTask), a pattern already in use several other places in this codebase for other asynchronous socket operations. I also added tests to verify that the receive timeout setting is respected in both blocking and non-blocking PooledSocket reads.