Properly return pooled blocks in SocketInput

[halter73]

When I was investigating #579, I discovered that all of the blocks getting finalized in the app I was using repro the issue were last leased by SocketInput.IncomingStart.

It appears that the last incoming block will never be returned even if it is fully consumed.

[DamianEdwards]

This seems like a really simple fix, yes? If so, I'd like to see this done in RC2.

[muratg]

If it's not a straightforward quick fix, let's move it to backlog

[benaadams]

Measurement across 1M non keep-alive requests; majority of the highlighted byte[] is the blocks not being returned early enough from the SocketInput

[sajayantony]

@sivagms - This might be the issue that Martin was trying to fix today due to the incorrect finalization. Do you want to take a look since you know the fix he was talking about?

[benaadams]

@sajayantony I assumed it was in this fix? #623 (though haven't measured)

[sajayantony]

btw.. @halter73 ryan has moved these benchmark and loadtest apps here

@benaadams 😫 I hadn't seen that PR and I've just joined this party :)

[benaadams]

@halter73 added PR for how I generated this https://github.com/aspnet/Performance/pull/48

[martinpf]

I noticed this as well last Friday. Under load, with a significant number of new connections being made, the finalizer queue falls behind and the memory blocks waiting in the queue can quickly exceed 1 GB. A simple fix for this would be to return the block held by SocketInput on connection close.