Fixes:
> `mailbox` of this room set to `test@domain@domain`
Previously fixed in 97a4d6c7bc, but it seems like we unintentionally
reintroduced this bug again at some point after that.
If're an admin and mess up the `users` list, you won't see "owner"
commands.
If you're just a regular room user (not an admin, not an owner), you'll
only see the `help` command in the `help` message.
Both of these situations may make you wonder:
- is that all there is?
- earlier I saw more commands, so what's going on?
Adding "and accessible to you" hopefully clears things up, or at least
it tries to make the help message more correct.
Now that we use Match() in allowAdmin() as well, it's awkward to
have it return `true` when called with an empty admin list.
No admins defined was taken to mean "everyone is an admin".
We can either have a `len(users) == 0` check in `allowAdmin` which
rejects the request, or we can change `Match()` so that it doesn't
return positive responses when called with an empty list. Doing the
latter sounds better. It's more natural that matching against an empty list
will yield "no match".
This can be improved in the future, to show some additional information
about each mailbox like:
- "how many users are in that room"
- "which users are in that room"
- "who is the owner of the mailbox"
This can all be done later though.
Checking using `settings.Allowed` is odd. Not all commands are related
to setting configuration settings. Admin commands are coming in the
future, for which this is certainly not the case.
We now do access checks early on (during command processing), so command
handlers can be clean of access checks. If we're inside of a command
handler, the user is privileged to run it.
Retrieving the settings object for each and every option was wasteful
I don't like how we're doing custom formatting for optionMailbox in many
different places. This should be redone.
