jellyfin_10_5: remove unmaintained version

[minijackson]

Motivation for this change

This version contains a vulnerability, and isn't maintained. The
original reason to have two jellyfin versions was to allow end-users to
backup the database before the layout was upgraded, but these backups
should be done periodically.

Original decision was on #93654, and in retrospect was a mistake, sorry about that.

This PR will be backported if there is no concerns from other maintainers, cc @nyanloutre, @purcell

This is a follow-up on the discussion that started on #120344.

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[purcell]

This seems like a good plan to me.

[dotlambda]

This also should fix #120389, and should partially fix #120388 + #120387 once backported.

This fixes #120387, not the others.

[dotlambda]

Do we need a changelog entry?

[minijackson]

It feels a bit weird to add it to the release notes, since it's going to be backported to 20.09

[dotlambda]

It feels a bit weird to add it to the release notes, since it's going to be backported to 20.09

Then I would say we only backport the removal of the package, not the change of the module.
So you need to split the commit in two.
And for 21.05 (i.e. in master) we can get rid of the stateVersion thing but add a changelog entry.

[minijackson]

That would mean it would break the config of anyone using Jellyfin and having a stateVersion < 20.09, which would be a shame considering the upgrade should go fine without intervention

[dotlambda]

which would be a shame considering the upgrade should go fine without intervention

Oh if there's no breaking change in Jellyfin, then this is fine. I just thought a breaking change was why jellyfin_10_5 was created in the first place.

[minijackson]

This was not really a breaking change, but more of a warning upstream that the database schema would be auto-migrated

[dotlambda]

@minijackson Will you make a PR for the backport?

[minijackson]

on it