fix(mysql): treat BINARY columns as Blob in Any type mapping

[barry3406]

Does your PR solve an issue?

Fixes #4132

Is this a breaking change?

Yes, this is a breaking behavior change.

Previously, MySQL BINARY(size) columns were mapped through the Any driver to AnyTypeInfoKind::Text, which caused a UTF-8 decoding panic (Utf8Error { valid_up_to: 4, error_len: Some(1) }) when reading raw binary data through AnyRow. After this change, those columns are mapped to AnyTypeInfoKind::Blob and can be decoded as Vec<u8> / &[u8] instead.

Code that previously relied on the (broken) Text mapping and was somehow decoding these columns as strings would need to switch to a binary type, so per Hyrum's Law this should land in the next major release (0.{x + 1}.0).

---

MySQL BINARY(size) columns report ColumnType::String with the BINARY flag set. The Any driver's type conversion checked the column type but not the flags, so BINARY columns got mapped to AnyTypeInfoKind::Text. Reading raw binary data through AnyRow then blew up with a UTF-8 decoding error.

Before:

SELECT * FROM test  -- where `id` is BINARY(16)
-- panics: Utf8Error { valid_up_to: 4, error_len: Some(1) }

After:

-- works: BINARY columns correctly mapped to Blob

The fix checks ColumnFlags::BINARY for String/VarString/VarChar column types and maps to Blob when set.

[abonander]

@barry3406 you somehow bypassed the PR template which asks you if there are any breaking changes, and if so, to characterize them. This is a breaking behavior change, so can you please add that to your PR description?

[barry3406]

Thanks for flagging — updated the description to explicitly characterize the breaking change under "Is this a breaking change?". TL;DR: any code that previously relied on AnyTypeInfoKind::Text for MySQL BINARY columns (and was somehow round-tripping the raw bytes as a string) would need to switch to Blob / Vec<u8>, so this should land in a major bump per Hyrum's Law. Let me know if you'd like more detail.

[abonander]

Using the BINARY flag is actually misleading, because it's also set for text collations with the binary property, e.g. utf8mb4_bin. This was the root cause of #3387 which resulted in a lot of complaints and headache.

There's some more context in https://github.com/launchbadge/sqlx/blob/main/sqlx-mysql/src/collation.rs#L1-L37 but the gist of it is that the main discriminator is the collation ID: binary (63) is a binary blob, everything else we just assume is a string (ignoring the character set, because it's actually always transcoded to the connection character set).

To avoid duplicating this logic, this could just forward to str::is_compatible() and [u8]::is_compatible().

I think it's also important to add a test for this, both to verify the fix and to guard against future regressions.