mkFirefox: add policy to accept added extensions

[Mikilio]

This commit adds extensions added via
profiles..extensions.packages to the policy. In consequence, the extensions are added without complaint and don't need to be enabled manually.

Description

While switching browser, I noticed that the current method of installing extensions, does not enable them. This is because the only firefox is allowed to install extensions, and it only provides one way to do so automatically.
As such, I have improved the method of installing extensions by using the intended way by mozilla to do this, without sacrificing reproducibility. This is achieved by "downloading" extensions from the nix store.

NOTE:

• The extensionPath uuid constant became obsolete through this because extensions don't need to be bundled anymore.
  This involves @rycee to change his convenient output derivations for firefox modules.
• This change relies on the fact that firefox modules from @rycee NUR repository expose a addonId. This needs to be documented somewhere
• nix fmt . made some unnecessary changes.

Checklist

• Change is backwards compatible.

• Code formatted with nix fmt or
  nix-shell -p treefmt nixfmt deadnix keep-sorted --run treefmt.

• Code tested through nix run .#tests -- test-all or
  nix-shell --pure tests -A run.all.

• Test cases updated/added. See example. (not applicable)

• Commit messages are formatted like

  {component}: {description}
  
  {long description}
  

  Maintainers and Involved:
  @chayleaf
  @onny
  @brckd
  @kira-bruneau

[JuneStepp]

FYI, I've tried this before and ran into some issues. I can't remember for sure, but it may have been to do with extension updates. Just take this as a reminder to test well.

[Mikilio]

I left this as a draft for now, as I'm just gathering input. I will run this myself for a while to see if there are any issues, and I'll keep an extra eye on extension updates (though in theory it should work, as the installation_url will change).

[Mikilio]

Seems to work, my extensions updated on a nix flake update and rebuild without me even noticing any weird behavior.

Let me know if I should implement this upstream instead.

Also @rycee :

• The extensionPath uuid constant became obsolete through this because extensions don't need to be bundled anymore.
  This involves @rycee to change his convenient output derivations for firefox modules.
• This change relies on the fact that firefox modules from @rycee NUR repository expose a addonId. This needs to be documented somewhere

[IanHollow]

I might be reading the implementation of this wrong and this could have already been the behavior before these chages but I don't understand what the point of having firefox profiles for extensions if they are going to be installed as firefox policies which installs them for all profiles.

[Mikilio]

@IanHollow That's true. And I was a bit careless about the fact, as I don't really use this difference.
It is also true, however, that this PR solves an issue of the current method of adding extensions, which is that extensions can't be activated and get the right permissions without user interaction, and that is by design from Mozilla.

I see three methods currently to go about this:

1. Move the setting outside of profiles and keep the current method.
2. Keep things as is and try to disable plugins for specific profiles.
3. Take this to nixpkgs instead.

[IanHollow]

@Mikilio yes I understand what you are saying. I personally do not use the profiles system either however I do think it is misleading to have the current system that way it is. I also understand that you did not design it this way originally.

In that sense this is not your problem to solve however I think it would be good to not mislead people to believe they are installing extensions for a profile when they are installing it for all of Firefox so I think that this should be changed to move the extensions out of the profile section until there is a way to install extensions not for all of firefox.

[Mikilio]

@IanHollow Based on that I presume that option 1 is preferred. That would mean adding an option like programs.firefox.globalExtentions that will allow to install extensions globally without user consent on a fresh install.
I will wait on feedback for this, but does this sound plausible so far?

[IanHollow]

yeah that is my preference to have something like global extensions but I do not maintain or have say in what is allowed to get merged. There are also considerations about making sure that this doesn't break peoples config without warning them. Unfortunately implementing something simple comes with fixing the problems that have come before you.

that being said I would just name it programs.firefox.extensions as to me it is implied that it is global.