feat(csharp/src/Drivers/Apache): add connect and query timeout options

[birschick-bq]

Adds options for command and query timeout

Property	Description	Default
adbc.spark.connect_timeout_ms	Sets the timeout (in milliseconds) to open a new session. Values can be 0 (infinite) or greater than zero.	30000
adbc.apache.statement.query_timeout_s	Sets the maximum time (in seconds) for a query to complete. Values can be 0 (infinite) or greater than zero.	60

[birschick-bq]

Looks good to me. One small nit (that I should have done already).

[birschick-bq]

Converted to draft because I'm trying to resolve failing tests

[davidhcoe]

Adds options for command and query timeout

Property Description Default
adbc.spark.connect_timeout_ms Sets the timeout (in milliseconds) to open a new session. Values can be -1 (infinite) or greater than zero. 30000
adbc.statement.query_timeout_s Sets the maximum time (in seconds) for a query to complete. Values can be -1 (infinite) or greater than zero. 60
TODO: Dynamically update HTTP request timeout when statement option is updated dynamically.

These have changed now.

[birschick-bq]

@CurtHagenlocher - A lot of churn on this PR - but I'd say it is ready for review, if you have the time. Thanks.

[birschick-bq]

HI @CurtHagenlocher - let me know if you have some time to review this PR. Thanks, again.

[CurtHagenlocher]

Thanks for the improvement! I've left a bunch of feedback.

[CurtHagenlocher]

nit: sets

That said, I feel like this is a dubious design choice. If there were a standard for command timeout properties in ADBC then we could hook into that from the wrapper. But if the consumer needs to have custom code anyway in order to set the command timeout, then I think we're better off just exposing the ability to set statement options through DbCommand -- it's equally usable for this case, and more generally useful for other unanticipated cases.

[CurtHagenlocher]

Also note that a particular driver may define this in a unit other than seconds given the lack of a standard.

As a suggestion, if the property name were on the ADO.NET connection string, it could be used much more transparently because the consumer will already have to have a generic mechanism for setting connection string properties. With this API, the consumer has to know explicitly that they're using a wrapped ADBC driver in order to be able to use the CommandTimeout API.

[CurtHagenlocher]

Note: because we can't pass the same cancellation token to ExecuteQueryAsync and the ReadNextBatchAsync, the runtime may exceed the query timeout

Can linked cancellation tokens be used for this?

[CurtHagenlocher]

nit: extra blank line

[CurtHagenlocher]

Thanks! Looks good overall. I do think the API for making the CommandTimeout work should be a little more consumer-friendly by allowing it to be set on the connection string. And for consistency, we should probably support DbConnection.ConnectionTimeout in a similar way. But these could be done in a followup. Remove that extra blank line and let me know if you want to check this in without those changes.

[CurtHagenlocher]

Thanks!