Send all enabled capabilities on CAP LIST

[ToxicFrog]

Notably, this fixes an issue with weechat (and possibly some other clients) where if you ever run /cap or /cap list after connection registration, the client will see the "CAP * LIST sasl" reply as downgrading the connection to drop all capabilities except sasl.

[ToxicFrog]

Just realized not all the internal capability tags match up to the on-the-wire ones even if you correct for _, so this is not fully baked.

[progval]

Oops, good catch.

You should be a global hashmap with @capability_names = @capabilities |> Enum.map(fn {name, {atom, _value}} -> {atom, name}) |> Map.new and use that to lookup the name for each enable capability.

[progval]

Only CAP LS 302 should have values in the reply, see https://ircv3.net/specs/extensions/capability-negotiation

[ToxicFrog]

Only CAP LS 302 should have values in the reply, see https://ircv3.net/specs/extensions/capability-negotiation

Yep, that's what the conditional on 312-316 is for -- if it doesn't get the 302 it'll call it with is_302 = false and you don't get the values.

17:46 <-- matrix cap LS 302
17:46 --> matrix :server. CAP * LS :account-tag batch draft/account-registration=before-connect draft/channel-rename draft/chathistory draft/message-redaction draft/multiline=max-bytes=8192 draft/no-implicit-names draft/sasl-ir echo-message extended-join labeled-response message-tags sasl=PLAIN server-time soju.im/account-required standard-replies userhost-in-names
17:46 <-- matrix cap LS
17:46 --> matrix :server. CAP * LS :account-tag batch draft/account-registration draft/channel-rename draft/chathistory draft/message-redaction draft/multiline draft/no-implicit-names draft/sasl-ir echo-message extended-join labeled-response message-tags sasl server-time soju.im/account-required standard-replies userhost-in-names

[progval]

Ah right, i got confused because you added another pair of cases for "CAP LS" next to "CAP LIST"; those won't ever run so you don't really need the new function either.

[progval]

ah but clients can still call them outside registration, nvm

[progval]

Could you add tests for each of these cases?

[ToxicFrog]

ah but clients can still call them outside registration, nvm

Yeah. There's not a lot of use for being able to do that until post hoc CAP REQ is also implemented (which I haven't touched here), but I wanted it for the sake of completeness and it wasn't hard to add.

Could you add tests for each of these cases?

Sure thing. Might not get to it until tomorrow though.

[ToxicFrog]

Done, and writing the unit tests also revealed a bug that weechat was fine with but which could have confused other clients, which is now fixed.