Provide QueryStatus V2 API

[arouel]

Overview

1. What GitHub issue is this PR addressing? Make sure that there is an accompanying issue to your PR.

   Fixes The errorCode and errorMessage fields of QueryStatus enum are not thread-safe #1370

2. Fill out the following pre-review checklist:

   • I am adding a new automated test(s) to verify correctness of my new code
   • I am adding new logging messages
   • I am modifying authorization mechanisms
   • I am adding new credentials
   • I am modifying OCSP code
   • I am adding a new dependency

3. Please describe how your code solves the related issue.

   • Introduce a new thread-safe data structure called QueryStatusV2 to keep the behavior of the QueryStatus enum for backwards compatibility.
     • The new data structure provides more metadata about the query status to better understand what is going on.
   • Introduce a new query status method at SnowflakeResultSet called getQueryStatus which return a QueryStatusV2.
     • The feature is only implemented for SFAsyncResultSet, and SnowflakeResultSetV1 throws a SnowflakeLoggedFeatureNotSupportedException.
   • Introduce a new query status method at SFSession called getQueryStatusV2 which return a QueryStatusV2.
   • Keep the existing methods and behavior stable for backwards compatibility.

Pre-review checklist

• This change has passed precommit
• I have reviewed code coverage report for my PR in (Sonarqube)

[sfc-gh-igarish]

If original issue is related to thread safety then why can't we fix it in existing API? Why we need a new V2 API?

[arouel]

@sfc-gh-igarish the existing data structure is an enum, and the only option I see to make it thread-safe would be to use thread-local variables for errorCode and errorMessage, but this may not solve the problem in all the use cases I can think of. On the other hand, we need more metadata about the query itself, therefore we opted for a new API call. What do you suggest moving forward?

[sfc-gh-igarish]

Any public API signature changes is a breaking change as it used by existing users. Please think of making existing API thread safe.

[sfc-gh-hchaturvedi]

Another suggestion would be to add the new API without changing the existing API so that they both can co-exist without breaking backwards compatibility. Also @arouel you mentioned there are other reasons why this API cannot be thread safe, care to elaborate?

[sfc-gh-igarish]

@arouel Please check PR comments.

[sfc-gh-pfus]

Do we need this as public?

[sfc-gh-pfus]

Definitely worth some deprecation comment now.

[sfc-gh-pfus]

I'm wondering if we should name it consistently to existing function - getStatusV2?

[sfc-gh-igarish]

Also why new function is not taking queryId as an argument?

[sfc-gh-pfus]

Because this is a function on resultSet - resultSet knows its queryId (even provides it by getQueryId).

[sfc-gh-igarish]

This is more about async execution. Are we providing resultset object before completed the query?

[sfc-gh-pfus]

This information is not accurate anymore?

[sfc-gh-pfus]

Implemented in #1579