Motivation for this change

• Version bump
• Split the lib and the server apps/tools in two packages
• curl and fetchurl, apache-httpd and others needs only libnghttp2
• Reduce closure-size for the most common use-case, ie all nix users since libnghttp2 is part of stdenv
• Previously we were pulling the whole apps suite in our nix-store when installing/building a package that depended on nghttp2 ; this solves it
• Allows to build nghttpx with systemd support on Linux -> it should be useful for the nghttpx service module @ixmatus
• Allows modification of the apps suite derivation without the risk of breaking fetchers or triggering a mass-rebuild

Closes #28376
/cc @fpletz @vcunat @wkennington

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
• 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 nox --run "nox-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Fits CONTRIBUTING.md.

v1.28.0 changelog:

lib: Add nghttp2_error_callback2 (GH-1062)
build: Add deprecation warning when spdylay support is enabled
Switch to clang-format-5.0
examples: Make client and server work with libevent-2.1.8 (GH-1039)
third-party: Update neverbleed
integration: Fix issues reported by the go vet tool. (Patch from Piotr Sikora) (GH-1047)
nghttpx: Fix affinity retry
nghttpx: Fix stalled backend connection on retry
nghttpx: Cookie based session affinity (GH-1024, GH-1066)
nghttpx: Expose additional TLS related variables to mruby and accesslog (GH-1031, GH-1038, GH-1057)

As of now, the nghttp2 derivation still ships its own shared lib for two reason:

1. Avoid breaking something outside of nixpkgs (although a package depending on nghttp2 when only the lib was needed was already doing something incorrect)
2. In case we need to upgrade nghttp{d,x} quickly (because of a critical CVE for example) we wouldn't be forced to also upgrade the system-wide libnghttp2 and risk breaking something else (curl or apache)

This is meant to be a temporary situation. In a future upgrade, we would have two solutions :

• link the apps statically (small increase of the nghttp2 closure size)
• or link the apps to the system-wide shared library (but we would lose the ability to have distinct upgrade policies for the lib and the apps)