closeConnectionFully is performed without lock

[rPraml]

Note: #127 would be our preferred solution

---

We now might have a better understanding what happened due our network outage.

In #114 we have already identified, that the connection.close may block.

In case of the DB2 driver (and maybe other drivers, too), the connection.close() will communicate with the database.
During closeConnectionFully we hold a lock, so that no other thread can obtain new connections (although if there are free ones)

In this PR we tried to do the closeConnectionFully outside of the scope of the lock. This should increase the multi thread performance of the pool.

Please take a look at these changes, if you would agree.

There are still two places, where the closeConnectionFully is called within the lock:

• shutdown -> should not be a problem
• reset -> may be a problem, because the pool will contiune with it's work only if the last connection is closed properly (if the connection pool is huge enough and you may estimate 30sec network timeout, this can take a lot of time)

So I'm unsure how to deal with the reset.
We assume, that restarting the pool took over 2 hours since our last crash.

We also added some more places, where logError is true (to be honest, I will always print the error in closeConnectionFully)

[rPraml]

Hello @rbygrave

Have you had time to watch this and can you give me feedback?
I think we have found a problem why our application sometimes practically hangs.
As long as the pool is busy with CloseConnectionFully, no further connections will be issued (pool is completely blocked)

I'm unsure what to do in "reset"? This should not block or at least should not block too long.

[rPraml]

Closing, as #127 is merged