First time user flow for halloy

[4e554c4c]

I have been mentioning for awhile on the IRC channel that it'd be nice to have a flow for first time users who haven't set up a config yet. In particular, the default config contains an autoconfigured server for Libera, with a preset (randomized) nick and channel.

I don't believe that autocreating a server and dumping a user into a channel is very useful—either for users or members of that channel. Instead, I think the user should be shown a dialog where they have to create a nick, add servers etc. I've done some user design mockups for this flow, and I have some recommendations of how this flow should be designed.

1. When the user starts halloy without an existing config, they should be dropped into a "welcome to halloy" window.
2. They are then asked to pick a default nickname (which halloy will automatically be modified on ERR_NICKNAMEINUSE
3. They are given a list of servers to add
   • I think that maybe 4 or 5 servers should be "included" for users to add by default. We would need to get consent from server operators to add them, of course.
   • Halloy could then temporarily connect to those servers and run /LIST to get a list of channels that users can add themselves into. If anything goes wrong in this step then no channels are shown
   • Libera should be autosellected, along with the #halloy channel to preserve previous behaviour, but a user can disable either if they like.
4. Users should be shown some basic guidelines/etiquette about IRC. I was thinking something à la sudo's "With great power comes great responsibility."
   • I think specifically it should me mentioned that irc does not keep history, and you should stay connected to a channel for at least an hour if you want a response.
   • Another good thing to note is that you can "mention" a user just by typing in their nickname, but doing so excessively is rude!
5. at this point, users can confirm and be sent to IRC.
6. [BONUS] An optional "UI tour". Several modern apps have this, where they dim all components except for a few, and show you what the buttons mean on first use. This should always be optional so users can get chatting, and it's probably a lot of upstream work so it shouldn't block any of this.

My thoughts on the technical design are as follows: (2) would require adding a default nick to the config outside of server blocks, which I think is already a good idea since it would help us build a "server add" UI. (3) is pretty complicated, but can be done incrementally. The /LIST functionality isn't essential and can be saved for later.

All 5 or so steps could be shown in a standard multi-step modal dialog. My general design for the "add server" UI is as follows: