GH-932: [JDBC] Fix memory leak on Connection#close due to unclosed Statement(s)

[ennuite]

What's Changed

Closing a Connection when there was one or more ResultSet that matched the following 2 conditions

1. hadn't been fully consumed
2. was obtained via a Statement instance of this Connection instance

would generate exceptions due to memory leaks.

Now, closing a Connection will first close all the Statement instances obtained via that Connection,
which has a side effect of closing all the ResultSet, and then proceed with the old closing logic. This
side effect is guaranteed by the JDBC Spec 4.3, chapter 13.1.4

The old closing logic was also slightly refactored to:

1. remove duplicate calls to ArrowFlightSqlClientHandler.close()
2. make sure that any exception generated during Connection.close() would be wrapped in a SQLException.

Closes #932.

[ennuite]

I'm not sure if I should further refactor the logic on ArrowFlightConnection.close() The changes so far are mostly to address the bug at #932 so I didn't touch the old logic a lot.

However, the way things are is that if an Exception gets thrown for example in AutoCloseables.close(clientHandler); we immediately throw the Exception and don't attempt to clean the rest of the resources.

I wonder if it would make more sense to use a logic similar to AutoCloseables.close() for every resource, and proceed with the cleanup until the end, and then throwing all the Exceptions generated.

The class ArrowFlightJdbcVectorSchemaRootResultSet uses this approach I'm mentioning for its close method.

Let me know if you want me to do that refactoring in this or another PR.

[lidavidm]

Yeah, I think it would be great to just build up a single list of AutoCloseables that we can pass to AutoCloseables so that an exception in one doesn't skip the rest, and hopefully that will clean up the logic too.