Fix encoding and decoding of MySQL enums in sqlx::Type

[alu]

fixes #1241

[abonander]

As it turns out, we didn't actually have a comprehensive test covering enum encoding and decoding for MySQL, so it's not clear if it ever actually worked correctly. Because this PR was opened without context and the MySQL internal documentation is garbage, it took writing and running the test to actually understand the situation. (The C API documentation mentions this briefly but also lists MYSQL_TYPE_ENUM as corresponding to ENUM fields just above it, so that's not much help.)

The problem is that how MySQL interprets MYSQL_TYPE_ENUM appears to have changed over time. In 5.7, it accepts string inputs with the type MYSQL_TYPE_ENUM and binds them correctly. MySQL 8.4, on the other hand, doesn't like it and throws an error:

1210 (HY000): Incorrect arguments to mysqld_stmt_execute

I suspect it's expecting the integer encoding that's mainly used internally. Or it just doesn't like it altogether; I'm not really sure and I don't want to get into it.

Both 5.7 and 8 return columns with MYSQL_TYPE_STRING and the ENUM flag set, so I'm not really sure what we were thinking when the code was originally written. This is why it's important to have real tests for things.

Your change did result in the correct behavior, with one exception: MySQL doesn't appear to care about the BINARY flag with enums and doesn't set it on returned columns, so MySqlTypeInfo::__enum() wasn't actually being considered compatible with what MySQL was returning. Removing the BINARY flag fixed it.

I've taken the liberty of pushing my changes. Since it's still your PR, you'll get the credit in the CHANGELOG. I don't think this is a breaking change because it fixes something that never really worked in the first place.

[alu]

@abonander

Thanks for the merge and your dedication and commitment.
I also did a local test and should have shared it with you. I am sorry.

I love this library with all my heart.