Backporting client support for caching_sha2_password auth

[fulghum]

The MySQL client API in our fork of vitess is limited to the mysql_native_password auth plugin, but the default auth plugin as of MySQL 8.0 is caching_sha2_password. This means that to use Dolt binlog replication, customers either have to change the default auth plugin in MySQL or they have to create a user that is identified with the older mysql_native_password auth plugin. This additional configuration step adds friction for customers wanting to try out Dolt binlog replication.

This PR pulls in selected changes from the tip of vitessio/vitess to pick up client support for connecting to MySQL servers that default to caching_sha2_password auth plugin (and will still fall back to mysql_native_password). All of these changes are pulled directly from vitessio/vitess, without any other changes mixed in.

I'm not aware of anywhere else in our codebase where we're using the MySQL client API from vitess. As far as I know, it's only used by the binlog implementation. That means this change shouldn't have any effect on other parts of Dolt/GMS, and I've gone ahead and run the Dolt CI tests against this change as a sanity check:

• Dolt CI Tests for Vitess caching_sha2_password upgrade dolt#5339

I've pulled over additional tests from the tip of vitess for this logic. I've also tested locally and confirmed that my binlog replication integ tests all pass with this change, and no longer require overriding the default auth plugin for the MySQL server. I've also started on some additional binlog replication integ tests to make sure we cover password/no-password and ssl/no-ssl.

[reltuk]

Looks great! Just a couple comments, probably lingering from upstream and not critical.