adminchannel, coretasks: improve handling of bot's current nick

[dgw]

Description

Tin, kind of.

There's a bit more esoteric detail in the commit messages if anyone's interested, but the short version is that we really should be moving toward a world where bot.nick always represents the bot's current nick in use—even if that doesn't match the config.

While we aren't there yet, this is a step (or two) forward on that path. I've made it so that coretasks' NICK event handler updates the bot's nick if it changes, and only warns for a change away from the config value.

Checklist

• I have read CONTRIBUTING.md
• I can and do license this contribution under the EFLv2
• No issues are reported by make qa (runs make quality and make test)
• I have tested the functionality of the things this change touches

Notes

On the way to writing this patch, I discovered that bot.change_current_nick() would send a NICK command to the server along with updating the bot._nick value. That's probably a bad idea, actually, and I didn't use it (also because it's redundant to send NICK thenickwealreadyhave). We should have another look at that method and rethink it…

[Exirel]

We should have another look at that method and rethink it…

Does this mean that the bot should change bot.nick only when the server tells that the nick has been changed? Does the server always reply back to the client after it sends a NICK command?

If yes: sure, we can change that behavior. If no: then we still need this method.

In any case, we also need a different, separate method that only set the current nick, something like this:

def set_current_nick(nick: str) -> None:
    self._nick = self.make_identifier(nick)

And keep change_current_nick() as a way to send a NICK command.

[Exirel]

It works as it is. However, if we are heading toward that direction, I suggest to add a set_current_nick() method to the bot (probably on sopel.irc.AbstractBot).

[dgw]

The way forward is probably to keep bot.change_current_nick() as-is, add the new bot.set_current_nick() method, and add NICK error handling to revert the bot's internal state if the server rejects a bot.change_current_nick(). I'd love to cleanly separate change and set, but there's no specified behavior in RFCs 1459 or 2812 about what the server should send (if anything) when a client changes nicks except for the error numerics. Modern/horse docs just has a "may" (not even in caps) in reference to servers sending a NICK command back to the originating user confirming the change. Sigh.

This PR is already way beyond the original scope, though, so I'm going to work on that stuff in a new branch based on this.

[Exirel]

This PR is already way beyond the original scope, though, so I'm going to work on that stuff in a new branch based on this.

Heh, you already got my approval, merge if you feel like it!