hash2curve: move oversized DST requirements to runtime errors

[daxpedda]

This PR introduces two changes:

• Remove requirements that were only relevant for oversized DSTs. Now these requirements are checked on runtime. While this is unfortunate, the currently limitations simply was that usage with regular sized DSTs incurred limitations that were not necessary.
• Change len_in_bytes from NonZero<usize> to NonZero<u16>. This isn't a big improvement because the error is just moved from expand_msg() to the various GroupDigest methods.

Companion PR: RustCrypto/elliptic-curves#1256.

---

I know I have been refactoring this API over and over again, but I actually think this is the last of it (apart from #872 with generic_const_exprs).

But for completions sake I want to mention the following from the spec:

It is possible, however, to entirely avoid this overhead by taking advantage of the fact that Z_pad depends only on H, and not on the arguments to expand_message_xmd. To do so, first precompute and save the internal state of H after ingesting Z_pad. Then, when computing b_0, initialize H using the saved state. Further details are implementation dependent and are beyond the scope of this document.

In summary, we could cache this part:

let mut b_0 = HashT::default();
b_0.update(&Array::<u8, HashT::BlockSize>::default());

Doing this requires passing ExpandMsg state, which would change the entire API having to add a parameter to every function.

However, as the spec mentions, the cost of not caching it is most likely negligible. We will see in the future if this shows up in benchmarks and if it does we can re-evaluate. I don't believe this will be the case though.

Alternatively, we could add a trait to digest which allows users to construct a hash prefixed with a BlockSize full of zeros that has been computed at compile-time. Which would also require no changes to the API except binding to this trait.

[tarcieri]

construct a hash prefixed with a BlockSize full of zeros that has been computed at compile-time

I don't think this is going to work in generic code until you can have const impls of traits.

That said it would be interesting to have const fn support for various digests. I've seen PoC impls in the past, though it's probably much easier now with const_mut_refs

[tarcieri]

Would like to see a https://github.com/RustCrypto/elliptic-curves/ PR before merging

[daxpedda]

Done in RustCrypto/elliptic-curves#1256.