aerc: add assertion to limit per-account extraConfig to UI config

[dryya]

Description

The aerc configuration file aerc.conf can contain 10 sections, but only the UI section supports what the aerc manual calls contextual configuration. This works by appending to the section heading either :account=name or :folder=bar. It's supported in config.accounts.email.accounts.<name>.aerc.extraConfig.*.*, as the aerc-accounts module applies a
function to add <name> to section headings.
However, this means home-manager will generate files like:

[general:account=default]
log-file=...

and the options will not be recognized by aerc.

This change only adds the account name to the UI section by adding a attrsets.filterAttrs check to mkAccountConfig. This could be confusing if a user only wants to apply their configuration to one account, and a possible alternative could be to change this option to something like config.accounts.email.accounts.<name>.aerc.uiConfig.*.
The error message about setting unsafe-accounts-conf = true has also been updated, to clarify it should be set
in the global programs.aerc.extraConfig section.

Checklist

• Change is backwards compatible.

• Code formatted with ./format.

• Code tested through nix-shell --pure tests -A run.all or nix develop --ignore-environment .#all using Flakes.

• Test cases updated/added. See example.

• Commit messages are formatted

[ncfavier]

I don't know much about aerc, but it seems to me that if the only per-account configuration allowed is ui, then we should restrict the per-account extraConfig to that. Otherwise the other settings will basically end up in the global extraConfig, possibly causing conflicts.

So I would either add an assertion, or make the type of the per-account extraConfig a submodule with just an ui option.

[ncfavier]

For example:

extraConfig = mkOption {
  type = types.submodule {
    options.ui = mkOption {
      type = confSection;
      description = "Per-account UI configuration...";
    };
  };

[ncfavier]

So it seems like we need a default value for both extraConfig and extraConfig.ui. Setting both to {} means that the per-account ui section will always be generated, which may or may not be a problem.

As alternatives we could make it default to null and only generate it if it's != null, or fall back to the assertion I mentioned.

[dryya]

OK, I've changed accounts.email.accounts.*.aerc.extraConfigback to typeconfSections` for consistency/parsimony, and added an assertion to make sure it only has a UI section. The assertion is a little ugly so let me know if it's OK or not.

I also think that as of before this PR, it was technically possible (although it seems unlikely) for a user to have something like accounts.email.accounts.mail.aerc.extraConfig."ui:account=mail" = { sort = "from"; }; in their config. After this PR, they would get an assertion. Should I mention in the error that specifying the account is not necessary and should be removed, or is there another way to deal with this?

(PS: I appreciate you guiding me through this process!)

[dryya]

I ran the test suite again and I think one could also fix the issue and keep it as a submodule by doing something like

    accountsExtraConfig = mapAttrs accounts.mkAccountConfig
      # only write this section if there actually is per-account config
      (attrsets.filterAttrs
        (_: v: v.aerc.extraConfig.ui != { })
        # could add || v.aerc.extraConfig.bla != {} in future
        aerc-accounts);

without needing any assertions. (Defaulting to null causes some issues because the INI generator wants to recurse through the values). But then, there would just be this odd-one-out section, which doesn't feel great.

[ncfavier]

Silently discarding non-ui sections doesn't seem great