Those need the driver to deal with the fact that the store is stateful. Those
tests can't be moved to the test suite because they use private functions.
We don't need to build a production key without persistent storage. Tests and
fuzzing continue to use the std feature to use the RAM implementation (that does
sanity checks).
This PR does the following things:
- Give incompatible representations for integers with different semantics:
- `usize` is used for natural numbers for the public API.
- `Nat` is used internally for natural numbers (essentially a stable `usize`).
- `Word` is used for sequences of bits representing words in flash.
- `Position` is used for word positions in the virtual storage.
- Only use fixed size integers to preserve overflow behavior between targets.
- Use little-endian representation instead of native representation for `Word`.
Alternatives:
- Run tests and fuzzing on 32-bits architecture (or some compatibility mode).
This approach would have better readability than the current solution (less
conversions at public API). However it would require additional setup and
might not be viable long-term by restricting machines on which fuzzing is
possible.
- Accept the behavior difference for tests and fuzzing. This approach would also
have better readability. However checking for arithmetic overflow (and other
`usize` related concerns like memory size) is more important.
