Refactor authentication server plugin mechanism

[dbussink]

This change implements a large refactor of the plugin authentication mechanism. This refactor needed for a number of reasons:

• The current AuthServer interface is not well designed. Many of the AuthServer implementations implement at least one if not multiple methods as a panic() as they are unused or they implement something never really called (like the salt generation). This indicates that the current interface doesn't abstract things well.
• Adding caching_sha2_password as a server side mechanism would make this interface problem worse. It would add even more methods that would have emply implementations / panic().
• It is impossible right now for a plugin to support multiple authentication mechanisms. The caching_sha2_password plugin allows for caching of passwords and could be used to improve for example the LDAP plugin. But we can't then still keep the mysql_clear_password as a fallback for such an improvement in the LDAP plugin.

Based on these issues, I'm proposing this refactor. It allows for a number of things that also make auth server implementations easier.

• An auth server can implement multiple auth methods. This allows for the above mentioned optimization for the LDAP plugin and many other improvements. Note that these improvements are not implemented here, but it opens up the opportunity.
• There are helpers for all the already supported authentication mechanisms plus basic support for caching_sha2_password. The last only supports TLS connections or Unix sockets right now, since the full authentication protocol is much complicated. The value of the latter is also debatable in the context of Vitess. It depends on a TLS certificate and private key also for the plain text full auth cycle and in that case, TLS would already be available as well anyway. For clients that want caching_sha2_password, switching those to enable TLS seems like a much simpler solution.
• With the helpers, specific interfaces are provided that plugins can implement. Those interfaces provide a simpler way than the complex Negotiate from before which might need to read packets etc. For these helpers, all reading / writing of the protocol is already dealt with and not something auth server plugin writers need to be concerned with.

Given the above advantages, I think the current setup is a better design and better fits what we'd want to use for authentication plugins.

Lastly, this does break any existing plugin implementations that are written in Go and that people might have done themselves in their own Vitess forks etc. I don't know if that's an expected interface / something that needs a larger announcement.

The functionality of all the built in plugins is exactly the same. They have been switched to the new internal APIs, but the external functionality, config files, configuration flags etc. have all stayed exactly the same.

Related Issue(s)

#5399 is related, but that was closed after only client side support for caching_sha2_password was implemented.

With the refactors here, it also becomes possible to implement caching_sha2_password for the server side component in Vitess.

Checklist

• Tests were added or are not required
• Documentation was added or is not required

Not really sure about the documentation. I don't think we document the internal Go interfaces, only things like configuration flags etc. for plugins that all stay the same?

[vmg]

This looks good to me. It's complex code but I don't see how to make it significantly simpler. It just has to do a lot!