Backport negative string size (or size too big) fix for Rails 7.0

[douglas]

Backports the negative string size (or size too big) fix to Rails 7.0 since we can't use master tip due to it being locked to Rails 7.1, which is not our case yet.

This PR should never be merged since we must either fix this odbc_adapter to work with Rails 7.0 or upgrade Campaigns to Rails 7.1.

[austenmadden]

I'm just mildly curious, executing this for my personal user in Snowflake returned a very large result. Does this work only because our snowflake connection user is more limited access wise so the table count is reasonable?

[douglas]

Hmmmmm, I didn't tried it yet, but according to the comment on this commit:

use SHOW TABLES query to address "size too big" errors for long table comments
This change fixes an issue with the `tables` call erroring out if attempting to
fetch any tables that have longer than 254 character comments on them. This fix
is based on the approach used by the patterninc fork of the gem, whose PR does
a great job of explaining the issue and idea behind the solution:

> The fetch_all function is using a bound 'remarks' column that is configured to
> have a max_length of 254 characters. That max length is not configurable and the
> column cannot be unbound. So when a table with a comment longer than 254 characters
> exists in the result set, we run into the negative string size (or size too big) error.

- patterninc#9

The primary difference here is that we're using `SHOW TABLES IN ACCOUNT` query,
which should return the same set of tables as `fetch_all` was returning before,
eliminating the need for an opt-in config flag.

Snowflake docs on the SHOW TABLES query:
https://docs.snowflake.com/en/sql-reference/sql/show-tables

So, I suppose @connection.prepare("SHOW TABLES IN ACCOUNT") would return the same as the previous stmt.fetch_all, of course, depending on the account being used.