Fix mapping status modes owner/admin/etc to op in TS6

[cooper]

I need to consider how I want to handle +qah/etc. forwarding to TS6 servers like charybdis which do not support these statuses.

We cannot assume that anyone with +q or +a or any mode higher than +o has +o in addition to whichever other statuses they have. Therefore it seems essential that a mode change of +q actually translates to +o. It must also be handled properly such that +qo does not translate to +oo and so on.

The question is whether it makes sense to do the opposite, i.e. to translate -o to -q—making ops on charybdis as powerful as owners on juno—or to instead immediately reverse the mode deop if done remotely by someone with a lower status. A third option would be to ignore +q and friends entirely on charybdis, which is the current behavior. The problem with doing that is that some channel actions require ops at a local level and may be ignored by charybdis.

I could also consider making it configure how you want this to behave:

1. Translate -o to -q
2. Reverse remote deops from servers without higher statuses
3. Ignore the existence of these modes altogether

Of course, all of this can be avoided by disabling juno's extra status modes.

[cooper]

Also, this currently happens:

[ircd::server] convert_cmode_string(): converted +qo 0c 0c (k.notroll.net) to +o 000AAAAAC 000AAAAAC (ts6.notroll.net)

The +q is weeded out but the parameter remains. This is bad.

[jlu5]

The most common way to deal with this is to just ignore the +qah entirely if the target doesn't support it. The reason why services set +qo and +ao instead of plain +q/+a is probably for compatibility for clients/bots that don't care about extended op statuses.

[cooper]

I was worried that some commands are ignored if you're not op, even remotely. Maybe I'm thinking wrong.

[cooper]

decided to do what @glolol said and remove unknown modes and their parameters, forwarding on without them