Regression: rejected client connection decrement pool counter

[smaldini]

After fix for #285, spring-messaging has observed a failing test scenario with the following stack:

2018-02-18 14:30:27,578 WARN [tcp-client-loop-nio-1] [io.netty.util.concurrent.DefaultPromise] - An exception was thrown by io.netty.channel.pool.FixedChannelPool$4.operationComplete()
java.lang.AssertionError: null
	at io.netty.channel.pool.FixedChannelPool.decrementAndRunTaskQueue(FixedChannelPool.java:324) ~[netty-transport-4.1.21.Final.jar:4.1.21.Final]
	at io.netty.channel.pool.FixedChannelPool.access$600(c.java:38) ~[netty-transport-4.1.21.Final.jar:4.1.21.Final]
	at io.netty.channel.pool.FixedChannelPool$4.operationComplete(FixedChannelPool.java:305) ~[netty-transport-4.1.21.Final.jar:4.1.21.Final]

The stack points to an illegal counting occurring in FixedChannelPool. The scenario involves an immediately rejected connection to reproduce.

[simonbasle]

After having looked at it today, it seems this double decrease of the internal counter of Netty's FixedChannelPool comes from

1. Netty's pool itself getting notified of the Channel acquision failure here
2. Our own Channel#closeFuture() listener that calls pool.release on the Channel, leading to an extraneous decrement and subsequent assertion error.

The closeFuture listener is registered when a Channel is created, which only means the Bootstrap could instantiate it, apparently. At least, the ChannelPoolHandler#channelCreated method is called even though the FixedPoolChannel might see the channel as not acquired.

Perhaps it would make sense to open an issue in Netty to see if there is a better way, or if this is ultimately a Netty bug @smaldini @violetagg ?