Move from ring to aws-lc-rs

There is some recent progress on quantum computers being discussed on
HackerNews and lobste.rs, and as a result of that timelines for when PQ
crypto would become essentially mandatory are being adjusted. Example:
https://words.filippo.io/crqc-timeline/

We pretty much have only one place in this entire codebase where any
sort of crypto happens, which is HTTPS for notifications support.

It seems that ring has essentially no plans to support PQ crypto for our
purposes. rustls/rustls#2801 briansmith/ring#1685

There's not really a reason to stick with ring, other than that it is a
prod-ready backend. But so is aws-lc-rs, and it seems to be the way
forward if you want PQ crypto today. Maybe that will change again in a
few years.

**The local dev workflow stays the same**, `cargo
build-daemon-firmware-devel` still uses rustcrypto which doesn't require
CC and doesn't have PQ crypto at all. We have no contribution docs for
how to build anything else anyway.

**Implementation:**

This opens a can of worms in building rayhunter-daemon in CI: We're
currently building ring using GCC cross-compilation toolchain from
Debian, which will build ring against **glibc**. Then we take that
library and try to link it against MUSL libc. The reason this works is
because ring's libc usage is very minimal, and the required symbols end
up being just the same as what MUSL libc exposes. The same can't be said
for aws-lc:

```
error: linking with `rust-lld` failed: exit status: 1
    = note: rust-lld: error: undefined symbol: __nanosleep64
            >>> referenced by urandom.c
            >>>               urandom.c.o:(do_backoff) in archive
```

So we fix that and link everything we build against MUSL libc (something
we should've done from the start anyway). The problem is that Debian
doesn't ship a MUSL cross-compilation toolchain, and the toolchain
available on https://musl.cc should not be downloaded directly in CI.
Which leaves us with a docker container from messense... That docker
container seems to be extremely popular for cross compilation across
GitHub projects, at least. I couldn't get other options to run reliably
(cross), or they were a too extreme change for my taste (using zig cc)

.github/workflows/main.yml

@@ -314,27 +314,25 @@ jobs:
       - uses: actions/checkout@v4
         with:
           persist-credentials: false
-      - uses: dtolnay/rust-toolchain@stable
-        with:
-          targets: armv7-unknown-linux-musleabihf
-      - uses: Swatinem/rust-cache@v2
-      - name: Install ARM cross-compilation toolchain
-        run: sudo apt-get update && sudo apt-get install -y gcc-arm-linux-gnueabihf
-      - name: Build rayhunter-daemon (armv7)
+      - name: Build frontend
         run: |
           pushd daemon/web
           npm install
           npm run build
           popd
-          # Run with -p so that cargo will select the minimum feature set for this package.
-          #
-          # Otherwise, it will consider the union of all requested features
-          # from all packages in the workspace. For example, if installer
-          # requires tokio with "full" feature, it will be included no matter
-          # what the feature selection in rayhunter-daemon is.
-          #
-          # https://github.com/rust-lang/cargo/issues/4463
-          CC_armv7_unknown_linux_musleabihf=arm-linux-gnueabihf-gcc cargo build-daemon-firmware
+      - name: Build rayhunter-daemon (armv7)
+        # Cross-compile inside messense/rust-musl-cross, which bundles an
+        # arm-linux-musleabihf cross gcc that aws-lc-sys needs.
+        run: |
+          mkdir -p "$HOME/.cargo-musl-cross"
+          docker run --rm \
+            --user "$(id -u):$(id -g)" \
+            -v "$PWD":/work \
+            -v "$HOME/.cargo-musl-cross":/cargo-home \
+            -e CARGO_HOME=/cargo-home \
+            -w /work \
+            messense/rust-musl-cross:armv7-musleabihf \
+            cargo build-daemon-firmware
       - uses: actions/upload-artifact@v4
         with:
           name: rayhunter-daemon