Nix support

[jacg]

trafficstars

This is an (incomplete) attempt to provide all the dependencies via the Nix Package Manager.

Unfortunately I am unable to get LTO to work: it compiles, but the Rust version of echo is many orders of magnitude slower than the C++ version.

In the process I have:

1. Added code to main.cpp which returns a failing status code when LTO has been enabled and the Rust version runs more than 10 times more slowly than the C++ version. The idea is to allow automated tests to check whether LTO is managing to optimize across the language boundary.
2. Added a GitHub Action which checks the Nix build.
3. Noticed that the original GHA is now failing. It looks like the latest stable rust toolchain uses clang 12, but ldd 11 is being used. I tried to change this in the env section of the GHA, but to no avail.

As it stands, there are 4 GHAs being run, of which 3 fail. Both the original actions fail because of the ldd 11 vs 12 problem. The Nix LTO=OFF one passes; the Nix LTO=ON action fails because the Rust version is too slow.

[jacg]

I have managed to fix the ldd 11/12 mismatch in the original GHA, at the cost of breaking the Nix one. This semi-fix is demonstrated in the Specify clang/ldd 12 in RUST_FLAGS commit which has been reverted.

However, it turns out that the original GHA fails the LTO speed test¹ As the logs of the actions in the parent repo have expired, I cannot verify whether it worked before in the GHA.

¹Hmm, there's something very curious going on here: The output is

Cross-language LTO appears not to be working as Rust is too slow:
Calling rust function, time elapsed: 1893911 ns.
  1893911 ns in Rust vs 100 ns in C++.
Calling c++ function, time elapsed: 100 ns.

even though, in the source code, lines 1 and 3 are printed after the function which prints lines and 2 and 4 has returned!

This has made me seriously doubt the timings. Consequently I tidied up the timing code and tried to ensure that nothing is optimized away, by printing the results of the speed test functions. In the process I found that changing the order in which the Rust/C++ test functions are executed has a noticeable impact on the ratios of their timings (factor of 6 swing: 60 thousand vs 10 thousand in C++'s favour). So I'm starting to suspect that some out-of-order execution optimizations are coming into play.

Additionally, at least one CI run reported a C++ duration of 0 ns.