nixos/nextcloud: Add support for caddy webserver

[onny]

Description of changes

This PR adds support for caddy webserver. Everything should work as before but with this you'll be able to choose between Nginx and Caddy as a web server:

services.nextcloud = {
  enable = true;
  webserver = "caddy";
}

• Update tests
• Update release notes

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
• 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.

[aanderse]

I'm pretty sure in the past the maintainers explicitly rejected supporting multiple web servers due to the already complex module code.

[onny]

I'm pretty sure in the past the maintainers explicitly rejected supporting multiple web servers due to the already complex module code.

Maybe we can merge this as an exception? UwU ^^

[aanderse]

That is entirely up to the maintainers.

ping @Ma27

[Ma27]

Sorry, but I'll remain opposed to the proposed change:

• maintaining HTTP routing for several webservers shifts an additional maintenance workload towards the Nextcloud maintainers that I'm not willing to take. Yes, we also support e.g. multiple database systems here, but in contrast to what the HTTP server is supposed to do it's a rather trivial thing IMHO (to be clear, it's already non-trivial on certain occasions to keep the nginx config working for several majors, so this is not about laziness from my side).
• there's some documentation in the manual on how to configure nextcloud with an alternative reverse proxy using httpd as example. This is also supposed to work with caddy instead.
• speaking of httpd, httpd and nginx are the most popular reverse-proxies/webservers out there and we already decided against directly implementing httpd support into the module, so I don't see any reason why we should make an exception now for an even less popular one (even though I acknowledge that there are fair reasons for caddy to be used).
• Finally, if we want to make our services modules independent of a reverse proxy (which is needed in case of e.g. php/phpfpm applications), we should do it as suggested in Develop a universal web service definition #22067 by implementing a "global" solution rather than blowing up every single module.

Hence I'm closing, from my PoV that's all to say about it. If there are some reasons you feel that haven't been addressed here, feel free to leave a comment anyways!

[onny]

Is someone still interested in using Caddy as a webserver, I added a practical configuration example to the NixOS wiki https://nixos.wiki/wiki/Nextcloud#Use_Caddy_as_webserver