nixos/stunnel: Make free-form

[chkno]

Motivation for this change

Allow the use of stunnel functionality beyond the very small (5%) subset explicitly supported by the NixOS configuration schema.
Also, add some tests of core stunnel functionality.

This supersedes PR #96401, which proposed just adding a few more config directives rather than a general escape hatch.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
    • I did this, but I noticed that nix-build . -A stunnel.tests doesn't run the tests as the linked documentation suggests it should. nix-build . -A stunnel.tests.stunnel does run the tests.
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 22.05 Release Notes (or backporting 21.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

FYI: stunnel maintainer @thoughtpolice, stunnel NixOS module author @lschuermann.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-ready-for-review/3032/733

[martinetd]

extraConfig never hurts... And adding tests is great, thanks!

[martinetd]

cheers!
I ran the new tests and confirmed it all works.

[lschuermann]

LGTM.

[mohe2015]

It's not possible to do this via a freeform module? Because I think that's preferred

[chkno]

@mohe2015 - freeform module - Ah! Yes! That is definitely worth trying. Thanks! I'm flipping this PR to draft now & will be right back with that.

[chkno]

Per @mohe2015 's suggestion, this PR now converts stunnel into a free-form module, rather than merely adding text-based extraConfig escape hatches.

This is now a more invasive change. I believe I've preserved backward compatibility: I added tests for the existing functionality in a separate commit before changing anything.

Please have another look. Thanks!

[martinetd]

hi! I've just been looking at converting something else to freeform and was pointed out at this: NixOS/rfcs#42

long story short, it looks like there's a generic way of creating freeform modules now instead of your generateConfig -- I'm not sure if that's important though as long as it works? clueless

that aside it looks good at first glance, I'd need to actually try a few old configs to convince myself it's mostly compatible but need to find some more time to do that..

EDIT: in particular for freeform things you could probably use pkgs.formats.ini or toml as is? it looks like a good match

[chkno]

@martinetd - Unfortunately, the stunnel configuration format is kind of a mess. It is much less sophisticated than INI or TOML. For example, it doesn't have any notion of quoting and escaping. Given a section name with a ] in it, the INI generator will escape it: [The \] Section]. Stunnel doesn't parse this way, and generating configuration as if it would be parsed this way would be confusing to users. The INI generator can be configured not to do this, and configured to use "yes" and "no" instead of "true" and "false", and we could remove keys with null values before handing off to the generator, and so on, but by that point it's just as much configuration-code to interface with the generator library as to just generate it directly, and requires future maintainers to read much more configuration-code to understand what's going on.

I added a brief note to the configuration generator with this rationale.

[chkno]

@martinetd, @chkno -- Eh, actually it's not so bad. Now updated to use generators.toINI. Thanks!

[martinetd]

Sorry, didn't mean to make you do so much work - I was happy by a config is messed up the generator code wasn't that bad... But well ok thanks ;)

I've read through it (looks fine) and verified it doesn't break my simple setup. Thanks!

[chkno]

Thanks, martinetd!

Any other reviewers have any feedback?

[chkno]

I'd like to progress this toward merge. The PRs already reviewed thread says that it is for reviewers to submit things there, not PR authors, so can reviewers either link this PR there or give feedback here about what is needed before this PR can be merged? Thank you!