We initially suggested to add SASL indeed but skipped it initially mainly for lack of time/effort. So I definitively agree that switching to SASL exchanges instead of our current custom one way message for the protocol v2 is a good idea.
On the patch, the principle looks good to me, but I would suggest going with a much simpler interface on our end and let people deal with all the subtlety of the java SASL API. After all, the only authentication we provide out the box is plain text authentication. Schematically, all that "supporting" SASL require is an interface to issue byte challenges from byte client responses. So I would suggest simply adding 2 new methods to IAuthenticator:
where SASLAuthenticator would be something like:
public interface SASLAuthenticator
public String getMechanismName();
public byte evaluateResponse(byte clientResponse);
and the current plain text authenticator could add a very simple implementation of that (without creating a full blown java.security.sasl.SaslServer).
This will change the IAuthenticator interface to add a new method, but I think supporting a new method is not a lot to ask for people having custom authenticator today, especially since if you don't care about the binary protocol SASL authentication, you can just have that method return null to start with.