bug#67220: 30.0.50; ERC 5.6: Prefer parameter-driven MODE processing in ERC

[J.P.]

"J.P." <jp@neverwas.me> writes:

> It turns out a not entirely frivolous use case for abiding by that RFC
> draft and *not* distinguishing between the two forms has arisen.
> Basically, a server may choose to support no channels whatsoever for a
> subset of clients, limiting them to direct messages only. To accommodate
> this, ERC will need to interpret both "CHANTYPES" and "CHANTYPES=" as
> expressing such a policy instead of sticking with its current behavior
> of only doing so for the "=" form and treating "CHANTYPES" as equivalent
> to ${default/fallback} (and thus also to "-CHANTYPES", which is clearly
> wrong).
>
> I think it's worth correcting this in ERC 5.6. Proposed changes
> attached. (The first patch is unrelated.)

These changes now live on master as

  3d87e343276 * Use modern fallback for channel name detection in ERC
  25d15391f26 * Normalize ISUPPORT params with empty values in ERC

If anyone experiences new difficulties related to detecting channel
names, these are likely to blame.