nixos/i2pd: refactor with freeformed submodule (RFC42)

[one-d-wide]

Description of changes

Fix #228182.

Refactor

• Redundant option declaration replaced with free-formed one (as proposed in RFC42).

Add

• String enumerator options in place of raw integer indexing
• Systemd service hardening
• Basic configure validation (only option names in i2pd.conf)
• Runtime credentials passing

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/)
• 23.05 Release Notes (or backporting 22.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
• Fits CONTRIBUTING.md.

[doronbehar]

Merge conflicts.

[doronbehar]

Hey @one-d-wide thanks again for working on this. Could you squash the last 2 commits onto your branch and then rebase to master? instead of merging master into your branch..

[one-d-wide]

Hey @one-d-wide thanks again for working on this. Could you squash the last 2 commits onto your branch and then rebase to master? instead of merging master into your branch..

Thanks. Is it in the correct state now?

[doronbehar]

The last commit fix typos,... could be squashed to one of the other commits, but no big deal in the meantime. In general, here in Nixpkgs, we prefer that every time you update a PR after a review, force push the changes, and always make the commit history in the PR logical and concise.

Secondly, why did you mark it as a draft? I would like to invite a review from an experienced module author.

[doronbehar]

BTW I must say that for a 1st time contribution, this PR is of impressive quality!

[one-d-wide]

Secondly, why did you mark it as a draft? I would like to invite a review from an experienced module author.

In a case I push the wrong thing to avoid mass-pinging of people, this is suggested in contributing.md. This PR is ready for review.

[doronbehar]

Secondly, why did you mark it as a draft? I would like to invite a review from an experienced module author.

In a case I push the wrong thing to avoid mass-pinging of people, this is suggested in contributing.md. This PR is ready for review.

Very well. If you will consistently force push to the same branch and update the same files, and won't change the target branch, you shouldn't unnecessarily mass ping many code owners.

[nixos-discourse]

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

https://discourse.nixos.org/t/prs-in-distress/3604/69