alloc independent `hash_to_curve` API

[krnak]

I would really appreciate, if some alloc independent version of hash_to_curve got into upstream.

By modifying the current API? Or adding an alternative API? @str4d

[krnak]

I tried to maintain the current API, ending up with these modifications

pub struct Hasher<'a, Field, Curve, IsoCurve> {
    domain_prefix: &'a str,
    _marker1: PhantomData<Field>,
    _marker2: PhantomData<Curve>,
    _marker3: PhantomData<IsoCurve>,
}

impl<'a, F, C, I> Fn<(&[u8],)> for Hasher<'a, F, C, I>
where
    F: FieldExt,
    C: CurveExt<Base = F> + CurveConstants,
    I: CurveExt<Base = F>,
{
    extern "rust-call" fn call(&self, args: (&[u8],)) -> C {
        let (message,) = args;
        ...
    }
}

#[cfg(feature = "unboxed_closures")]
fn hash_to_curve<'a>(domain_prefix: &'a str) -> Hasher<'a, $base, $name, $iso> {
    Hasher::new(domain_prefix)
}

Unfortunately this requires unstable features unboxed_closures and fn_traits.

Another small but necessary change is to move ISOGENY_CONSTANTS to some public trait.

You can find a proof of concept here: https://github.com/jarys/pasta_curves/tree/unboxed-closures

[str4d]

bls12_381 has an alloc-free hash-to-curve implementation (https://github.com/zkcrypto/bls12_381/tree/main/src/hash_to_curve). That one has been tracking the RFC draft, whereas the one in this repository is intentionally point-in-time (as we need consensus compatibility with the version of the RFC draft that the Zcash protocol uses). There is also IIRC an implementation over in the elliptic-curve Rust Crypto crate, but I don't recall whether it is alloc-free.

Ideally we could have a generic alloc-free implementation in the group crate (or possibly elliptic-curves if a more wide-scale reorganisation of traits happens). In the meantime, I'd like to conceptually reduce the number of distinct implementations we have, so I'm inclined to take the bls12_381 API (after https://github.com/zkcrypto/bls12_381/pull/90 is reviewed and merged) and port it over to here, assuming there have been no changes to the RFC draft that would make it incompatible. I'll keep the API @jarys gave above in mind while reviewing the bls12_381 PR.

[krnak]

I'll keep the API @jarys gave above in mind while reviewing the bls12_381 PR.

You don't have to. I was just an attempt to make required changes without breaking the curent pasta_curves API.