bug#48598: 28.0.50; buffer-naming collisions involving bouncers in ERC

[J.P.]

Hi, this is just a routine update/checkpoint rather than a bump for
feedback.

I fear that in the rush to cobble together my original report, I may
have given the false impression I was prepared to move quickly on this.
And that in turn may have triggered some frustration with folks eager
for a fix or at least something test drivable amid the mass exodus from
Freenode. For any callousness on my part re over-promising and
under-delivering, please accept my apologies.

Firstly, I wanted to highlight some prior art done in this area by Kevin
(CC'd), who contacted me out of band. I've incorporated their latest
update to erc-join.el in my proposed WIP patch set. It's based on these
discussions [1].

My other changes primarily focus on implementing what I'd only
previously provided half-baked placeholders for, namely

  1. Network-based connection identities

  2. Support for identical channel and query targets across networks

Other changes are more or less minor tweaks, most reflecting shifts in
my understanding of the living standard [2] and/or the library itself
[3][4].

If I can sign off with an appeal to any and all interested folks: please
step up and collaborate on this bug, even if that means my having to
pass the baton or redo much of what's currently on offer. Thanks.


Notes
~~~~~

[1] https://lists.gnu.org/archive/html/emacs-devel/2015-03/msg00088.html

    https://lists.gnu.org/archive/html/emacs-devel/2018-02/msg00664.html

[2] Correction: in my original report, I mentioned possible problems
    with case mapping in ERC. After seeking out more informed opinions
    on the matter, I no longer feel my concerns were entirely justified.
    And in any case, they're not worth prioritizing, ATM.

[3] Re my (perhaps wanton) deletion throughout the library of existing
    fallback-oriented logic for selecting connection identities.

    Currently, there's a lot of attention paid to graceful degradation
    in this department with questionable obvious benefit, IMO. Rather
    than splitting hairs over inferior/degenerate fallbacks, which ends
    up, for example, sewing confusion by shoehorning something like
    erc-session-server (the dialed address) into a value basically meant
    for networks, why not just opt for precision and blow up when met
    with lapses in our understanding of IRC (in hopes of encouraging
    quicker, cleaner fixes in the future)?

    In the discussion for bug#23438 "24.5; ERC autojoin should use
    erc-autojoin-domain-only searching channel keys" (which merged with
    bug#25349 "25.1.90; erc join -vs- passwords" and led to a patch),
    the participants make this problem pretty plain:

    > Nikolay Kudryavtsev <nikolay.kudryavtsev@gmail.com> writes:

    >> Though one thing - I'm not sure whether you even need to use "or"
    >> here. Would there ever be a case where erc-session-server is nil,
    >> but there is erc-server-announced-name?

    > I don't actually know, so I just swapped them out of paranoia.

    Not to pick on these fine folks (this kind of equivocal reasoning in
    this specific area predates their bug by a decade plus). But going
    forward, I think it makes sense to at least note such uncertainty in
    the code if not face it head on by dropping this convention of
    indiscriminately relying on fallbacks. Worst case scenario: our lack
    of IRC know how is betrayed (at everyone's expense, temporarily) and
    we're forced to up our game.

    With this set of WIP patches, I'm trying to somewhat upend this
    "fallback" trend by making a de facto hard dependency of the
    networks module (library wide) and delegating to it all duties
    concerned with identifying a specific connection.

    BTW, their bug itself was of course legitimate, but their solution
    didn't account for proxies (e.g., "localhost") or the concept of a
    network, really.

[4] To any old timers still using this client: if you would be so kind
    as to explain the reasoning behind erc-default-recipients being a
    list rather than a single target, that'd be terrific (TIA).