"Erroneous Nickname" errors on swear words

[kegsay]

So 0.3.1 made the bridge follow the RFC (mostly) and everyone was happy. However, some networks have swear word filters on nicknames, which produce:

2016-07-18 08:54:36 ERROR:client-connection Server: irc.freenode.net ($SWEARWORD[m]) Error: {"prefix":"morgan.freenode.net","server":"morgan.freenode.net","command":"err_erroneusnickname","rawCommand":"432","commandType":"error","args":["*","$SWEARWORD","Erroneous Nickname"]}

This then triggers another reconnect ad infinitum. I am not even going to attempt to maintain a swear word list for the bridge. Instead, we should just assume that for whatever reason that nick is bad, we can't do anything about it, and then assign a random hex string (much like how IRCds resolve nick conflicts on netsplits in fact).

[ara4n]

(there's also https://matrix.org/jira/browse/SYN-729 for a partial mitigation by banning 'bad' words on the synapse side)

[kegsay]

Right so the way IRCds seem to do this is they return 432 (erroneous nick) as a challenge much like they would return 433 (nick in use) on connect. They then hold open the connection for a bit to give you time to return a valid nick, then time out. There is no RPL_WELCOME sent.

Interestingly, XChat has a rather horrible UX for this where it erroneously states:

TestFucking already in use. Retrying with TestFucking_...

Most likely because it is assuming that any challenges are due to them being in use, even though the raw log clearly states Erroneous Nickname. Fun times.

[kegsay]

Tested patch and it "fixes" it (as best as we can fix such things...).