Unpredictable behaviour in fasthttp.hijackConn after closure

[askolesov]

Currently, the way fasthttp.hijackConn behaves is different from what can be expected with the net.Conn interface.

Normally, when you close a net.Conn, if you try to read or write again, you get errors.

But with fasthttp.hijackConn, when you close it, it gets cleaned and put back in the pool. If you try to read from or write to it again, it can cause two problems:

1. If it hasn't been reused yet, it might cause null reference exception because the underlying connection is nil.
2. If it has been reused, you might end up reading from or writing to a completely different connection, which is very bad.

I suggest not reusing hijackConn when KeepHijackedConns is enabled (it still will be reused when this option is disabled). This might make things a bit slower, but it will make the behavior more predictable for users.

We've had issues with this in our project, and it seems like the easiest way to fix them is with this pull request.

[askolesov]

Here is the fix: #1629