SNOW-1313790: Separate cloud-vendor-specific dependencies from thin JAR

[wesleyhillyext]

It's great to see the new (experimental) thin JAR option for the Snowflake JDBC driver.

Currently, that has dependencies on SDK components for all of AWS, Azure, and GCP. However, I'd expect a majority of customers will not use Snowflake regions backed by all three cloud vendors. For example, we don't use GCP-backed Snowflake regions, and though we want to try the thin JAR, it's the GCP SDK dependency which is preventing us from doing so right now (we end up with some library version clashes around gRPC until we complete some separate library upgrade work).

My impression is that the vendor SDK dependencies are neatly isolated to the implementations of SnowflakeStorageClient. So my suggestion would be to consider splitting those three implementations into separate snowflake-jdbc-thin-aws, snowflake-jdbc-thin-azure, and snowflake-jdbc-thin-gcp JARs. The main snowflake-jdbc-thin JAR would then have to load the available ones with reflection at runtime. If asked to perform a stage operation for a cloud vendor without that JAR, it would have to throw. Perhaps there are complications I'm not aware of, but that's the general idea.

The idea is to help customers manage the sometimes significant transient dependencies they otherwise get by forcing all three cloud-vendors; especially GCP which tends to have some of the trickiest dependencies but a small minority of Snowflake customers need. It would also reduce final application sizes, which seems to be another frequent request I see in this project's issues.

We could probably do something to explicitly omit certain cloud vendors' dependencies from our builds, but thought you might be interested in this feedback during the experimental phase.

[sfc-gh-dszmolka]

hi - thank you for taking the time to provide feedback and inputs for the thin jar, really appreciated ! we'll consider it for the future plans for snowflake-jdbc-thin.