Execute Stored Procedures Directly

[tkyc]

Continued work from #547.

Points of interest:

1. In order to use parameter names and indexes interchangeably for acquiring/setting parameter eg. cstmt.getXXX or cstmt.registerOutputParameter, the driver will need to continue to use metadata query to get the parameter names when the new CS property useFlexibleCallableStatements=true (default behaviour).

2. xp_sqljdbc_xa calls have a special case registering their output parameters for CHAR and BINARY types as non-PLP. Prior to this PR, because cstmts calls were wrapped the RPC parameters sent to the server were defined within the sp_execute calls and so it wasn't necessary to do so.

3. To read the output parameter return values, parsing the tds response is deferred to the getXXX calls. So, if a user executes a cstmt but doesn't get/read the output params, the return values in the tds response will be in limbo/waiting for resolution. In such case, on statement close we will now skip these return values in the tds response which is safe to do.

4. Prior to the PR, it was possible to get the return value from sprocs as a byte array. This shouldn't be possible and this is corrected in this PR. It will throw a casting exception.

5. To allow for unordered setting/registering of parameters, we'll need to continue to use a metadata query for the parameter names (this goes along with point 1 when useFlexibleCallableStatements=true).

6. If outParams are null then likely the statement was closed, so we throw an exception.

7. Potentially we can skip building the type definitions as this is no longer needed since we send the RPC params directly. However, this breaks AE and so needs more investigation.

8. For user defined functions (UDF) to work, we need to know when the TDS's response return value is for a sproc or a UDF. To do so, new logic was added to parse the TDS's response to determine this.

9. On the main branch for datetime (datetime, datetime2), the RPC call would always send the parameter as datetime2(7). However, since the cstmts are wrapped, the real param definition was set in the sp_executesql/sp_prepexec by building the type definitions in buildParamTypeDefinitions which are affected by the datetimeParameterType CS property. Since we are executing cstmts directly, datetime (datetime, datetime2) will now do the RPC with the exact datetime parameter definition. Meaning, depending on the datetimeParameterType CS property, datetime2 will be sent in the RPC as datetime2(3) exactly by default (which was the prior behaviour done by/indirectly set in the build type definitions) or sent plainly as a datetime.

10. New CS property useFlexibleCallableStatements. Default behaviour is useFlexibleCallableStatements=true, and in such case the driver will continue to use sp_sproc_columns. Otherwise, when useFlexibleCallableStatements=false, setting/registering parameters for callable statements require the following:

• a) Setting/Registering callable statement parameters must be exclusively by index or exclusively by parameter name. A mix of index and parameter names will not work.
• b) Setting/Registering callable statement parameters must be in same order as the sproc definition. Setting the parameters in an adhoc order will not work.
• c) Sprocs with cursorable methods will continue as is with sp_sproc_calls regardless of each new CS prop scenario.

[David-Engel]

Please add tests that exercise CallableStatement with useFlexibleCallableStatements set to false and validate success and failure cases. We should detect if they are mixing named/index and throw an error. Not sure if we can detect out of order params.