Created CRHF trait and conform RescueCRH impl

[alxiong]

Description

Part of: #168

Changes include:

• add trait CRHF
• Provide struct FixedLengthRescueCRHF and struct VariableLengthRescueCRHF conforming to the trait.
• add trait CommitmentScheme
• Provide struct FixedLengthRescueCRHF

NOTE:
to hack around some nightly-only feature on using const generic in an expression, we have a temporarily excessive generic parameter on FixedLengthRescueCRHF<F, INPUT_LEN, INPUT_LEN_PLUS_ONE> which will be fixed in the future.

---

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 (main)
• 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

[tessico]

What about replacing all the current calls to RescueCRHF with (Fixed/Variable)LengthRescueCRHF?

[alxiong]

What about replacing all the current calls to RescueCRHF with (Fixed/Variable)LengthRescueCRHF?

Yes I have considered this, the problem is, currently RescueCRHF::sponge_with_padding() -> Vec<F> always succeed whereas sponge_no_padding() -> Result<> could fail.
Some functions that internally call padded version API also have a function signature that won't fail. If we switch to VariableLengthRescueCRHF::evaluate() -> Result<Self::Output>, since we need to conform with trait CRH then we will have to return a Result and do unwrap().

A possible middle ground is we declare another API: VariableLengthRescueCRHF::evaluate_safe() -> Self::Output which internal call evaluate() and unwrap() once cuz caller know it won't panic.

[mrain]

Should we do the same thing to STATE_SIZE

[alxiong]

currently still usage in transcript in jf-plonk that utilize this constant here, I think we might be able make it consistent after #159 ?

I will think more meanwhile

[mrain]

Suddenly I feel like we should export these 2 constants. Perhaps we could make them trait/struct dependent?

[alxiong]

I tend to disagree. I think it's intuitive that CRHF_RATE is a internal detail of CRHF, thus try to hide from public is sensible. whereas STATE_SIZE is a parameter of our Rescue permutation instance, which like A and MDS should be public.

I think the current visibility makes sense to me.

[mrain]

But what if the user need to know the "rate of compression"?

[alxiong]

why would the user want to know that? I couldn't think of a use case for now.

alright, maybe I will just expose them. I don't see much harm either.

[alxiong]

changed back in 7b77e79

[alxiong]

Update: during refactoring of @tessico's suggestion

What about replacing all the current calls to RescueCRHF with (Fixed/Variable)LengthRescueCRHF?

I need to use FixedLengthRescueCRHF::<F, INPUT_LEN, 1>::evaluate() inside our Commitment, but currently the length is just a field (variable) instead of a constant value (meaning not knowable at compile time), thus compiler complains.

Therefore this forces me try the following:

pub struct FixedLengthRescueCommitment<F: RescueParameter, const INPUT_LEN: usize>(PhantomData<F>);

meanwhile, I might as well just declare a trait CommitmentScheme in this PR.

[tessico]

Looks good, I left some final minor comments.