INT-3433 commit

INT-3433: Fixed NIO deadlock (or timout if the CallerBlocksPolicy is used) with Bounded ThreadPoolTaskExecutor.

JIRA: https://jira.spring.io/browse/INT-3433

I have signed and agree to the terms of the SpringSource Individual
Contributor License Agreement.
I agree in general that (3) is preferable and, yes I understand that although we're looping on this IO, we may still service other IOs and eventually free up an assembler so this IO can complete. But my concern is stressing the system unnecessarily when it's already stressed.

Using the TCP stack to apply back pressure to the clients is a little more difficult with NIO than it is with regular sockets (where you can simply not read and the socket will back up - it will just happen automatically when the server is busy). Clearly, though, with thousands of clients, NIO is the only way to go.

I need to give it some more thought, but one thing that comes to mind is to use your approach (skip the IO when there's no assemblers available) and have `readPacket()` return a boolean (or throw a marker exception) that tells the selector thread that the IO was not performed and, instead of enabling `OP_READ` immediately, somehow defer it for, say 100ms. That way, we'd avoid spinning the CPU and apply back pressure on the socket.

We'd just need to always timeout the `selector.select()` (instead of only when the `soTimeout` is set) so the selector thread can re-enable `OP_READ` for any deferred IOs.