xC: use MONITOR for PM user tracking #3
See https://ircv3.net/specs/core/monitor-3.2, notably implemented by Freenode.
Use this to track users we have an open PM buffer for but don't share a channel with. Use a
str_map indexed by their nickname, limit the amount of entries by the MONITOR value--first come, first served. Right after connecting, this becomes all PM buffers. Unsubscribe once we start sharing a channel, subscribe once we stop or a new PM buffer is opened and we don't share a channel at the moment.
See comment in
irc_handle_quit() for more considerations: when a PM buffer is open, set an "offline" flag in the user when he QUITs and upon ERR_NOSUCHNICK. Then try to add them to the MONITOR list. Once they reappear on a common channel for the first time (we may later come to share multiple channels), look for PM buffers where the flag is on and write an "is back online" message. The same holds for RPL_MONONLINE. Strongly consider not printing the message when the user isn't on our MONITOR list (which, by the way, may contain entries not yet accepted by the server), as the timing might be wrong--or use, e.g., "has appeared on #channel". Think further of possible race conditions.
On RPL_MONOFFLINE, write an "is offline" message. Both of the new messages will be
BUFFER_LINE_UNIMPORTANT, which is slightly questionable because you might be waiting for the event.
Consider what to do about the shitty Dark Science InspIRCd-3 that ignores degesch's autojoin (and maybe even USERHOST) but apparently not ZyklonB's, strangely enough. This would affect reliability. RPL_WELCOME should just work. Check the highly unlikely eventuality that hooks eat it along the way. Also note that the "command_delay" option, which can be used to circumvent this issue, has a misleading name.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?