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.
This does not do anything useful just yet.
It will be hooked to access control checks later on.
Wildcards are converted to regular expressions, because it was simpler
to do that than to write (or include) some ugly wildcard matcher library.
It also provides more flexibility, should we wish to use it later.
Regular expressions should also work well performance-wise.
We compile wildcards to regexes early on (during configuration
processing) and fail if we detect a bad pattern. This is meant to
catch various problems (typos or other mistakes) that could happen.
For this to work, configuration building had to be redone, since it can
now return an error. This may be useful in the future for validating
other configuration settings.
Related to https://gitlab.com/etke.cc/postmoogle/-/issues/1
In various places, we build messages using `Sprintf` before passing them
to `Notice()`.
If we let `Notice()` do string formatting, we run the chance of having
it try to format our already-preformatted text. If our text includes
format references (e.g. `%s`), it would cause a problem (`%s(MISSING)`).
One way to trigger it is to change the bot prefix from `!pm` to `%pm`.
Doing so, `sendHelp()` would create some help message which contains
`%pm` references. `Notice()` would then try to process them as well,
leading to a bunch of `%!p(MISSING)m` in the final text.
Sanitizing options on Get() ensures that when someone asks
for a given option which may not be defined (`nosubject`, `nosender`),
we'll return a valid value (`'true'` or `'false'`) and not `''` (empty
string, undefined).
This way, users do not need to wonder if "nosender is not set" is
handled like "true" or "false" or in some 3rd way. They also don't need
to think about "how to unset this setting, now that I've set it to something".
Options will appear to have a default sanitized value no matter if
they've explicitly been set or not.
The `NoSender()` and `NoSubject()` getters are just there for
convenience, so that we won't need to do casting in other places.
The configuration setting is called `Hide*` instead of `Show*`, because
it's backward compatible with existing configuration settings.
This is useful for when you setup an email forwarding inbox and you're
always sending to it through the same email address. In that case, you
don't need to see the email address in each Matrix message.
In the future, another similar `bool` setting (`hide-subject`) will land,
which controls whether the email's subject is shown in the final message
or not. That setting can make use of most of the same setup (all of
`handleBooleanConfigurationKey`).
