openpgp: reconsider xxhash-rust / xxh3 hasher usage
The xxhash-rust crate seems to only really support x86 architectures, from what I can tell. Some internal functions only support x86 and x86_64 compilation targets, but silently do nothing on other architectures. For example, in xxhash-rust/src/xxh3.rs:_mm_prefetch, the code only includes conditional compilation blocks for architecture-specific vectorization primitives on x86 and x86_64, but the function is still used regardless of architecture in other parts of the module. This is also the case in other functions, where only architecture specific code paths are provided, with the default / generic code path seeming to be "do nothing". The whole crate looks like it only compiles on non-x86 architectures by accident.
I tried running the xxhash-rust test suite on different architectures, but also ran into problems. The two dependencies for running tests to validate results are very broken too (xxhash-c-sys is broken on 32-bit architectures due to hardcoded pointer sizes, and twox-hash produces unexpected results on all non-x86 architectures, it seems to have the same problem as xxhash-rust), so any tests using those two crates as a reference for "correct" results should be taken with a grain of salt. However, at least on some architectures (powerpc64le), the xxhash-rust test suite failed with xxh3 producing wrong hash values in some cases. That doesn't exactly inspire confidence.
Additionally, the xxhash-rust project's choice of license is rather weird for a Rust project ("Boost Software License 1.0" ONLY), and it is the only crate in the entire dependency tree of Sequoia / Octopus that uses this license. At least BSL-1.0 is apparently (L)GPL-compatible, but it would still complicate the "effective" license terms under which Sequoia + Octopus will be made available (for example, in my Fedora packages).
Original commented on the PR: !1169 (comment 814106641)