Expose SASL as a config option

[polyzen]

I'm having a very hard time (as a Rust beginner) figuring out how to hack in an SASL connection with url-bot-rs, and I haven't found a dependent crate that actually uses SASL, to use as an example.

WeeChat lets you specify the SASL mechanism. A similar config option could be used here to state whether to not use SASL, use plain authentication, or use external authentication (which afaik would then use this crate's client_cert_* options).

~~The reason I want to use SASL is so I can join channels that require registered/identified users. This is especially important on Freenode, where unsetting +r is just inviting spammers.~~ Turns out you can also identify during connection if you do it via the password option, eg. setting it to <account>:<password> for Freenode. Thanks @panicbit.

[aatxe]

(Mostly restating the original post, but with more details)

As it stands, it should be possible to use SASL as it is used in practice by the majority of users (i.e. with AUTHENTICATE EXTERNAL using CertFP). This was implemented in #132.

There's two main enhancements to be made here.

The first is to change the format of the AUTHENTICATE command to be more typed. Namely, it'd be useful to make it something like AUTHENTICATE(SaslSubCommand) where SaslSubCommand looks something like:

enum SaslSubCommand {
  /// Specifies the plaintext authentication mechanism.
  Plaintext,
  /// Specifies the external authentication mechanism.
  External,
  /// Passes along some authentication data.
  Data(String),
  /// Terminates the sequence of authentication data with a `+`.
  Terminal
}

The second is to add a config option that selects the authentication method to use, and the related code to do the authentication according to the selected method. This should probably be added to ClientExt and will be somewhat similar to (but not replicating the contents of) ClientExt::identify.

There's already some existing operations to support SASL there, but they don't do any of the actual sequencing for the authentication. It'd be nicer to have something like ClientExt::sasl_auth which would send the appropriate auth request with the expected data. For example, with EXTERNAL, we should send:

AUTHENTICATE EXTERNAL
AUTHENTICATE +

which should correspond to (with the first part implemented):

Command::AUTHENTICATE(SaslSubCommand::External)
Command::AUTHENTICATE(SaslSubCommand::Terminal)

As of right now, there isn't an intention to implement the ecdsa-nist256p-challenge mechanism since (to my knowledge) it is unused.