Add userhost-in-names capability

[vanosg]

Fixes: #1368
Fixes #1188

One-line summary:
Add IRCv3 userhost-in-names capability

Additional description (if needed):
This updates channel records with hostmasks received from the userhost-in-names capability, and nothing more. Useful for cases where WHO queries are disabled.\

[vanosg]

Current implementation questions:

• Should enabling userhost-in-names not send a WHO?
• Is it OK to have "competing" userhost requests? ie, a WHO and NAMES request toggling CHAN_PENDING flags; will this cause a desynch? (I don't think so)

[thommey]

It should still send WHO because we are also interested in account info.
Where does CHAN_PENDING get set on a names request? the names response is sent without a request after a JOIN and afaik eggdrop never requests names

[thommey]

Still need to add users, not just update hosts (and on updating hosts we might need to call chghost)

[vanosg]

It should still send WHO because we are also interested in account info.

We don't get a WHO response at all (is my understanding)- so we won't get any account info.

Where does CHAN_PENDING get set on a names request?

Eggdrop gets a JOIN for itself (gotjoin), and sends reset_chan_info. reset_chan_info sets the channel into a CHAN_PENDING status until reset_chan_info calls refresh_who_chan, which sends a WHO #channel to the server. Once the 315 is received, CHAN_PENDING is removed and CHAN_ACTIVE is set.

More specifically to the question, it's not ever set right now as a response to NAMES, but after the gotjoin().

the names response is sent without a request after a JOIN and afaik eggdrop never requests names

From RFC, a 353 (names reply) is sent automatically after a JOIN. ( "If a JOIN is successful, the user is then sent the channel's topic (using RPL_TOPIC) and the list of users who are on the channel (using RPL_NAMREPLY), which must include the user joining") Without Eggdrop sending a NAMES, we're getting a 353 right now "for free".

[vanosg]

Putting this here for probable later discussion:

• got352or4 adds the WHO_SYNCED flag.
• got315 calls sync_members()
• sync_members clears users from the userlist that don't have the WHO_SYNCED flag set.

... because right now I'm debating running NAMES through got352or4 (hello got352or3or4!)

[vanosg]

We're going to pause development on this feature until we can find a server that disables WHO. There are several implementation questions we have that can't be answered by our speculation, we need to see this "in the wild".

[ZarTek-Creole]

I provided two IRC servers to @vanosg