Use the simpler `cachix watch-exec` to populate our cachix cache

[exarkun]

While setting up cachix for PrivateStorageio/PaymentServer I noticed some things could be simpler. Here they are.

[codecov[bot]]

Codecov Report

Merging #438 (ae9a814) into main (52e2296) will decrease coverage by 0.11%. The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #438      +/-   ##
==========================================
- Coverage   95.22%   95.10%   -0.12%     
==========================================
  Files          62       62              
  Lines        8013     8013              
  Branches     1035     1035              
==========================================
- Hits         7630     7621       -9     
- Misses        277      288      +11     
+ Partials      106      104       -2     

Impacted Files	Coverage Δ
src/_zkapauthorizer/lease_maintenance.py	87.56% <0.00%> (-5.95%)	:arrow_down:
src/_zkapauthorizer/tests/common.py	95.86% <0.00%> (-2.48%)	:arrow_down:
src/_zkapauthorizer/tests/test_client_resource.py	98.30% <0.00%> (+0.21%)	:arrow_up:
src/_zkapauthorizer/tests/matchers.py	84.70% <0.00%> (+1.17%)	:arrow_up:
...rc/_zkapauthorizer/tests/test_lease_maintenance.py	98.00% <0.00%> (+1.50%)	:arrow_up:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

[hacklschorsch]

I don't know how to implement cachix - so probably these would be answered by going through the docs - I'll still ask since I feel lazy right now:

1. The build-wheel job seems to not use cachix. Is that intentional?
2. The linux-tests job uses cachix, and seems to also store build artifacts. But do we really want to cache test results? Can we (easily) / should we maybe only cache build results but not test results?
3. The restore_cache and save_cache steps in the macos-tests job - are they valid for cachix?

[exarkun]

I don't know how to implement cachix - so probably these would be answered by going through the docs - I'll still ask since I feel lazy right now:

1. The `build-wheel` job seems to **not** use cachix. Is that intentional?

I think that was accidental. However, I don't think the wheel job will benefit much from cachix. Unlike the test jobs it doesn't have to build any of the Python dependencies. Python itself and other similar dependencies will be retrieved from the NixOS cache. The wheel itself could be cached on cachix but it will usually different so the cache won't be usable and "building" it only takes a few seconds anyway (it's just a zip archive of the source).

I'm okay leaving this uncached for now and if we notice the wheel job is taking too long we can revisit this idea.

2. The `linux-tests` job uses cachix, and seems to also store build artifacts.  But do we really want to cache test results?  Can we (easily) / should we maybe only cache build results but not test results?

cachix itself doesn't give us any way to do this filtering so I don't think it will be easy to change this behavior. I think caching and not caching each have arguments in their favor here so I'm happy to stick with the easy option until we develop stronger feelings.

3. The `restore_cache` and `save_cache` steps in the `macos-tests` job - are they valid for cachix?

Unfortunately we can only use cachix for the Nix builds. So the macos-tests job still uses CircleCI's built-in caching features. I think that's probably okay, at least for a while. The macos-tests job's cache doesn't seem to be growing unreasonably - probably because it only ends up caching the Python wheels we explicitly put into the "wheelhouse" directory. This will grow as new versions of our dependencies are released, but probably very slowly. Right now the cache appears to be 30MB and takes 3s to restore.