Always close or rollback connection to avoid possible leak

[rPraml]

@rbygrave This is a part of #107 and it would be great, if this can get merged soon.

what have we done here:

in #107 I've added a mode CloseWithinTxn.FAIL that complains, if you call close without a previous commit or rollback.

The ConnectionPool behaves in this mode very similar as the DB2JCC driver. The driver does not allow close within an UOW (UnitOfWork, =Transaction).
As reported in #107, a getSchema() can cause to start a UOW. so just a try-with-resources will not work any longer.

In this PR, I added commits or rollbacks in the tests, so that it will follow the JDBC spec: https://docs.oracle.com/javase/8/docs/api/java/sql/Connection.html#close--

It is strongly recommended that an application explicitly commits or rolls back an active transaction prior to calling the close method. If the close method is called and there is an active transaction, the results are implementation-defined.

I discovered the following behaviours:

• DB2JCC requires commit/rollback before active transaction, otherwise close() will throw an ERRORCODE=-4471, SQLSTATE=null
• Postgres does not allow commit/rollback when autocommit is on

[rPraml]

This fixes the connection leak with DB2.
When we just close the connection (=return to pool) and there is an open UOW, the pool cannot close the connection on trim and the pool restarts. This connection stays open and also their tcp/ip connection (more detailed explanation in #107)