* https://github.com/libgit2/libgit2/releases/tag/v0.28.0
* https://github.com/libgit2/libgit2/releases/tag/v0.28.1
* https://github.com/libgit2/libgit2/releases/tag/v0.28.2
* https://github.com/libgit2/libgit2/releases/tag/v0.28.3
* https://github.com/libgit2/libgit2/releases/tag/v0.28.4

Supported since 0.5 at least

Removes Python 2 support.

https://github.com/libgit2/pygit2/blob/v1.0.3/CHANGELOG.rst

…e hash dir

This has several advantages:

1. It takes up less space on disk in-between builds in the nix store.
2. It uses less space in the binary cache for vendor derivation packages.
3. It uses less network traffic downloading from the binary cache.
4. It plays nicely with hashed mirrors like tarballs.nixos.org, which only
   substitute --flat hashes on single files (not recursive directory hashes).
5. It's consistent with how simple `fetchurl` src derivations work.
6. It provides a stronger abstraction between input src-package and output
   package, e.g., it's harder to accidentally depend on the src derivation at
   runtime by referencing something like `${src}/etc/index.html`. Likewise, in
   the store it's harder to get confused with something that is just there as a
   build-time dependency vs. a runtime dependency, since the build-time
   src dependencies are tarred up.

Disadvantages are:
1. It takes slightly longer to untar at the start of a build.

As currently implemented, this attaches the compacted vendor.tar.gz feature as a
rider on `verifyCargoDeps`, since both of them are relatively newly implemented
behavior that change the `cargoSha256`.

If this PR is accepted, I will push forward the remaining rust packages with a
series of treewide PRs to update the `cargoSha256`s.

fetchcargo: use flat tar.gz file for vendored src instead of recursive hash dir

No upstream release yet, but libssh2/libssh2#402
has been accepted by upstream devs.

Original advisory:
https://blog.semmle.com/libssh2-integer-overflow-CVE-2019-17498/

Re #73662

According to https://endoflife.software/programming-languages/server-side-scripting/ruby
ruby 2.4 will go end-of-life in march, where the new release of nixpkgs
will be cut. We won't be able to support it for security updates.

Remove all references to ruby_2_4 and add ruby_2_7 instead where
missing.

Mark packages that depend on ruby 2.4 as broken:
* chefdk
* sonic-pi

libgit2: 0.27.8 -> 0.28.4

It's a little suspicious that the binaries are (apparently)
linked statically, but I assume upstream has some reasons (e.g. speed).