Avatica double-adjusts timestamps when calling Array.getResultSet()

If you go into AvaticaResultSetConversionTest and delete the timeZone property for the connection, which is currently set to "GMT", several getString() and getArray() tests start to fail. The getString() failures are self-explanatory – the expected value has become incorrect because of the time zone change – but the getArray() failures are tricky. They're double-adjusting the timestamps:

• Once when they call getObject() (which invokes getTimestamp() with the connection's default calendar, which was previously GMT but is now the system default).
• Then, in ArrayImpl.equalContents() the arrays are converted to result sets for traversal via Array.getResultSet() , which uses the same time zone as the "factory" result set and eventually invokes getObject() again, thus applying the time zone offset twice.

This is a bug in the implementation of Array.getResultSet() that only manifests when the array contains timestamps and when the connection default time zone is anything besides GMT, and this is not currently covered by tests. It's easy to cause the failure, however, by changing the connection default time zone for AvaticaResultSetConversionTest to anything besides GMT or UTC.