Refactor hash-to-curve around digest::XofReader trait

[burdges]

Description

Addresses several concerns:

Hash-to-field and hash-to-curve are logically consumers of XoFs. The hash-to-curve spec is written this way. Also, ristretto exploits this, likely so do other elligator deployments, including some ed25519 protocols. It follows polymorphic implementations should expose hashing directly from XoFs, but still push users towards compliant domain separation. In fact, arkworks' hash-to-curve cannot currently use shake cipher suites, or other XoFs, only sha2 ones, which excludes some elligator curves, and all curves with security levels above 128 bits.

At the same time, the hash-to-curve spec creates messy dependencies across its internal XoF boundary. In particular, a security parameter plays several roles but depends upon the curve, or even the specific hash-to-curve. We hide this annoying security parameter in the MapToCurve trait. It's plausible but uncertain if digest::core_api::BlockSizeUser might permit computing this security parameter from the hash selected.

Arkworks' Field as UniformRand cannot be made constant-time, so this exposes hashing-to-fields directly. At present, this hashing-to-fields is not constant-time because arkworks' field arithmetic is not constant-time, but at least one could deploy a protocol built with hash-to-field and later do constant-time field code.

We do not expose hash-to-field in exactly the style of the hash-to-curve spec. A hash-to-curve for bls12-381 has 128 bits of security, but one could build a curve with higher security with the same base field or whose group order matched the base field, and then require shake256.

Arkworks needs considerable other boilerplate for hash-to-curve. We make a true default-per-curve hash-to-curve possible.

We preserve roughly the old MapToCurve interface, which already looked suitable for some snark friendly hash-to-curve schemes, although perhaps not within its security assumptions. It's likely the new XoF interface supports some other snark friendly hash-to-curve schemes.

XofVec is an ugly hack, but frankly so is this whole sha2 XoF. This PR removes a lot of needless allocations elsewhere though.

We should discuss this new interface further of course, so no curves PR for now, but doing one looks pretty trivial.

supersedes: #627

closes: #629 & #630

---

Before we can merge this PR, please make sure that all the following items have been checked off. If any of the checklist items are not applicable, please leave them but write a little note why.

• [ ] Targeted PR against correct branch (master)
• [ ] Linked to GitHub issue with discussion and accepted design OR have an explanation in the PR that describes this work.
• [ ] Wrote unit tests
• [ ] Updated relevant documentation in the code
• [ ] Added a relevant changelog entry to the Pending section in CHANGELOG.md
• [ ] Re-reviewed Files changed in the GitHub PR explorer

[burdges]

Do you guys want this PR to be from a non-organizational repo so that you can change it?

I could move somewhere else or @mmagician could move it to be internal or something else?

[mmagician]

@burdges any progress on splitting up the hashing PRs as we discussed offline, for reviews to be more "digestible"?

[burdges]

I've been too distracted lately but I'll try to get to it next week. It's really not that hard.

[burdges]

Odd, why does https://github.com/arkworks-rs/algebra/pull/643/commits/15fc1a56ccfc8c911372f2411337a0ab04a24138 not appear above now?