Better channel burst system

[SadieCat]

Currently when a user joins a channel they get a names list. This is pretty sparse and doesn't contain a lot of the useful data that a client needs so they need to wait for the JOIN and then send a WHO to retrieve additional data. This is non-ideal and increases delay for rendering the UI. We can do better.

I'm proposing we add a draft/rich-channel-burst cap which changes this to send something more useful for clients. This should probably include a WHOX response line for each user and maybe other things too (e.g. if a user has away-notify then away messages).

[TheDaemoness]

This problem came up as part of a larger discussion about the possibility of Libera.Chat supporting bot mode, and how it's not ideal to give clients another reason to need to WHO channels on join.

The half-baked idea I threw out at the time was to have a flags-in-names capability which would suffix the nick (or host, in case of userhost-in-names) with flags as-returned-by RPL_WHOREPLY. $ seems like it would work as a separator, but there may be better options. This would indicate away state, bot mode, status prefixes (redundantly, could possibly omit the existing prefixes in RPL_NAMREPLY with this cap), operator status, and whatever server-specific extensions to the flags there are.

While fairly straightforward, it doesn't generalize to other forms of user metadata, and in particular omits users' realnames and servers (and hop counts, I guess). But maybe that should be the responsibility of a hypothetical metadata v3 spec, which would hopefully have a way to avoid relaying the same information about a user once per shared channel.

[glguy]

If the client could specify that it was interested in away or bot mode or other subsets that would reduce the message load.

If the client could issue one-such query for all channels it was joined to at once, or specify a list of channels that might cut down in duplication.

(Just some ideas)