[WIP] Add nix to projects (using nix)

[Pamplemousse]

⚠️ This is a Work-In-Progress that does not even work (yet?) ⚠️

As I am struggling to integrate nix to OSS-fuzz, these PR (with #6338) helps to keep track of the progress, and help gather feedback on approaches taken.

Context

As part of a fellowship, I work on fuzzing nix; More details on https://discourse.nixos.org/t/tweag-fellowship-fuzzing-nix-0 .
One of the "end-goal" of the project is to integrate nix to OSS-fuzz; This PR is a step in that direction.

Approach

Unlike #6338;

This approach aims to stay "close" to the build system used upstream to avoid maintenance burden:

• use nix to:
  • manage build reproducibility (i.e. if it works upstream, then it works in the Dockerfile; no extra management of dependencies)
  • ease run time reproducibility (copy the pertinent content from the store in $OUT)
• leverage upstream's autotools system:
  • build nix libraries without hassle
  • add compilation of fuzz target
  • add extra flags to libraries (relies on Don't overwrite user provided lib*_LDFLAGS NixOS/nix#5175) for better fuzzer coverage and sanitization

(Another pretty similar approach would be to compile statically using pkgsStatic packages from nixpkgs in upstream's flake.nix, but this is not well supported, and many such packages currently fail to build...)

Disadvantage: does not work (yet).

TODO

• make fuzzer compilation work and test
• apply sanitizers to nix libraries
• don't clone a fork:
  • push for Add a matrix of stdenvs to the flake NixOS/nix#4996 to be merged to get a clang environment
  • integrate fuzz targets upstream NO (see [WIP] Add nix to projects (using nix) #6317 (comment))
  • integrate local.mk upstream NO (see [WIP] Add nix to projects (using nix) #6317 (comment))
• compile and test coverage binary(ies)
• add auto_ccs to projects.yaml if maintainers are OK
• sign the google-cla thing

cc @regnat

[google-cla]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[google-cla]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[Pamplemousse]

I am having a hard time building for coverage, see #6385 .

[Pamplemousse]

@googlebot I signed it!

[Pamplemousse]

About integrating the fuzz targets, and related local.mk (makefile) upstream:

1. If a fuzz target is put upstream, then its related local.mk should be upstream too.
   The idea is to avoid bitrot; Separating those two artifacts will lead to a fuzz target being harder to maintain from upstream only;
2. The recipes in local.mk relies on fuzzing-specific flags, that are not present in the upstream code, and hard to express in the upstream building logic (Port Nix to Meson NixOS/nix#3160 (comment)). Furthermore, OSS-fuzz opinionated values over these flags conflicts in places with nix build system (example: --stdlib=libc++);
   i.e. nicely integrating local.mk upstream is not possible, and hence would need an associated build.sh not to bitrot.
3. a. build.sh is required by OSS-fuzz to be present here;
   b. It has a specific interface (i.e. environment variables) to deal with the abstraction OSS-fuzz wants to provide (i.e. fuzzing engine and sanitizer agnosticity).
   The second point in particular makes it annoying to introduce a build.sh-like upstream, because the abstraction expected by OSS-fuzz conflicts with upstream's.

So:
Fuzz targets, local.mk, and build.sh should live here.
(at least until it will be possible to comply with OSS-fuzz's build abstraction from upstream's build system - for example if NixOS/nix#3160 gets merged).