[FIXED] Close() may not release resources immediately

[kozlovic]

When a connection is closed very quickly after being created, there
was a race condition that could lead to the connection object still
being referenced (and therefore holding resources) until the first
ping interval elapsed.
This was because the pinger was created in spinGoRoutines() which
was itself created as a go routine. When the Close() call was made,
the ping timer may still be nil (therefore no way to stop it), but
then created in the go routine (which caused the reference to the
connection object). By default, it means that the connection object
would be held for 30 seconds.
Doing connect/close in a tight loop would show the process size
growing.

This PR refactors where we create the pinger and the use of the
wait group. There had been a change in a past to attempt to fix
a WaitGroup panic. I believe this approach is more stable. We do
create the pinger and bump the wait group in processConnectInit,
under connection lock. The doReconnect() go routine waits for
this wait group on entry and then on iterations where a failure
occurs after we know we have started the go routines.
In case of failures in the reconect loop, some state has also been
properly reset (namely the connection's buffered writer).

Resolves #368

Signed-off-by: Ivan Kozlovic [email protected]

[coveralls]

Coverage decreased (-0.5%) to 94.631% when pulling 35b4f0c on fix_close into 93a833d on master.

[derekcollison]

LGTM