Refactor: Final iteration on load/store

[reneme]

Description

This should be the final iteration on the big/little endian helpers for now (modulo the eventual removal of the legacy ptr-based overloads).

The patch fulfills three main objectives:

1. Remove the inherent code duplication of the load/store overloads for big-endian and little endian
   This is achieved by introducing detail::load_any<> and detail::store_any<> with a template parameter Endianness. By passing this all the way to the lowest-level overload, we can do the distinction once and implement convenience overloads without duplicating them each time (+more duplication for legacy overloads)
2. Support strong types and enums that wrap unsigned integers
   This allows for things like: load_be<MyIntStrongType>(some_bytes), or store_be(some_enum_value). It makes working with strong types and enums more convenient when loading/storing them.
3. Allow loading/storing collections of unsigned integers
   Before, one could load/store multiple variables at once (passed as variadic parameters). Now, its possible to pass ranges of integers (similarly to typecast_copy()). That is useful initializing and extracting internal hash states (that are collections of uint64_t), for instance.
4. constexpr
   The whole range of features described above may also be used at compile-time. For instance, to initialize algorithm parameters that need a certain endianness.

Quick and Dirty Benchmark

Running ./botan speed both on the feature branch and on the master commit it is based on, both compiled with clang-15 on ubuntu 22.04 (running in WSL). Is that a reasonable smoke test?

Many algorithms actually seem to benefit from this patch (without modifying the used load/store overloads). For instance, AES encryption/decryption (using NI extensions) clocks in at a 7% speedup. Is that even realistic? 😲 Keccak seems to suffer slightly. For instance, the SHAKE throughput is about 2% less.

Here's the full data set: bench_loadstore_refactoring.txt

[coveralls]

coverage: 92.048% (+0.04%) from 92.006%
when pulling dde4cba on Rohde-Schwarz:chore/more_loadstore_convenience
into 13c7e5f on randombit:master.

[reneme]

Rebased after #3888.

[reneme]

Rebased and resolved conflicts after #3908 got merged.

[randombit]

I’m a little skeptical of this change simply because it’s +900/-300 just to keep feature parity, and the new code is rather more complicated than what came before, which does not seem like a simplification so much to me 🙂 but I can see the benefits re strong types and consistent constexpr.

As a smoke test botan speed seems to me fine, but 7% for AES-NI seems quite surprising! For one, because AES-NI uses SIMD_4x32::load_le which doesn’t use this load infrastructure at all - it basically is just a _mm_loadu_si128. (And likewise for stores.)

I’ll look into benchmarks on my machine asap. Approving in so far as - assuming we can clearly demonstrate no significant regressions - change seems ok.

[reneme]

I'd like to argue that the this adds almost 400 lines of test code. 🙂 However, admittedly, the code is denser than before, that's for sure.

[randombit]

I checked times of this PR vs master on some algorithms that seemed likely to be impacted by performance of load/store (especially hash functions), nothing notable so ok to merge.