bug#51753: ERC switches to channel buffer on reconnect

[J.P.]

These are just some related notes, mostly intended for posterity. Feel
free to ignore. Thanks.


I think at some point it'll be worth exploring the best time and place
for forgetting the current connection's origins with respect to whether
it sprang from an automated reconnect. The latest iteration of this
patch does this via `erc-cmd-JOIN'. But that's a bit of a compromise and
one that will hopefully be replaced with something smarter down the
road.

Ideally, resetting would occur immediately after all reconnect-related
JOINs have happened. As might be obvious, doing this ultimately involves
tracking more state, including but not limited to "JOINedness". In the
case of server-initiated joins, that implies doing so across sessions
[1]. For client-initiated ones, it means tracking request context. While
IRCv3 features like "label responses" were designed specifically to
assist with the latter [2], that doesn't mean we can't do so manually,
given sufficient motivation.

Indeed, when armed with a reliable way to uniquely identify a "logical"
channel subscription across connections [3], it becomes possible to do
this manually by stashing callbacks or continuation instructions. (Some
people may know this as the "command" pattern.) The real question then
becomes whether it's worth the added complexity.

BTW, if anyone has alternative ideas for a temporary solution (other
than `erc-cmd-JOIN'), please speak up. I originally thought about doing
the resetting in a subset of /CMDs originating from typed user input,
but that seemed more prone to inconveniencing users who may have long
incorporated the underlying functions into custom code (firing on
connection) [4]. One way around this would be to only do the resetting
when a user actually enters something at the prompt, but unless you want
that to happen on *any* /CMD, we'd need special handling [5] for the
handful desired (possibly chosen via configurable option).


~~~

[1] A related issue is the means of detecting whether we're joined to a
    channel. With traditional pub/sub services (IRC channels are really
    just "topics"), it's in the client's interest to stay abreast of its
    subscription status. And the service API also typically exposes a
    way for a client to query for this out of band. ERC *does* track a
    channel's JOIN'd state, but it's a bit hampered by legacy features
    related to how targets are currently handled (via
    `erc-default-recipients' and functions that access/mutate it).

[2] https://ircv3.net/irc/#labeled-responses

[3] "Logical" meaning including serially, i.e., spanning disconnects.

[4] In ERC's case, these commands aren't designated as being primarily
    intended for /interactive use (`erc-cmd-JOIN`, being one such
    function, naturally suffers from the same flaw).

[5] Hopefully something more flexible than adding/removing properties,
    like `process-not-needed', which creates problems when trying to
    override /CMDs.