bug#29108: 25.3; ERC SASL support

["J.P." <jp@neverwas.me>]

"J.P." <jp@neverwas.me> writes:

> An earlier version mentioned that users can customize per-network SASL
> settings by let-binding `erc-sasl-*' options and `erc-modules' around
> `erc-tls' invocations. I'm doubtful this is a sustainable approach and
> would guess that a more declarative solution is the likeliest way
> forward, perhaps something based on connection-local variables.
> 
> That said, I think users still need a practical solution to tide them
> over in the short term, one that doesn't involve hooks or timers.

Actually, now I'm thinking an even earlier version (from bug#49860) had
the most sensible approach for per-network SASL settings all along, and
that's simply recognizing `:user' and `:password' symbols as values for
`erc-sasl-user' and `erc-sasl-password' (possibly even as defaults). The
module then just uses whatever's stored in `erc-session-username' and
`erc-session-password' (and obviously inhibits the sending of a server
password).

> And since this module already takes a snapshot of its own options on
> initialization (for reconnection purposes), we might as well revert to
> mentioning let-binding, but this time also stress (maybe in an
> Advanced chapter) that local modules are still being fleshed out and
> that third-party implementations aren't yet encouraged.

Given the other realization above, I guess it's no surprise that I've
again flip-flopped on mentioning let-binding and have reverted to the
opinion that we shouldn't officially commit to local modules at all and
should minimize advertising their presence and behavior until we've
arrived at a workable solution for granular (network/nick/channel-aware)
user options.