keccak: refactor to a closure-based API

[newpavlov]

The new API provides a better way for exposing support for parallel processing in implemented backends and resolves the issue with branching on each application of a Keccak permutation.

[newpavlov]

I am not sure how to deal with the SIMD "backend". It adds support for operating over u64x2/4/8 and allows user to select the width, while the trait expects to select optimal width using target feature detection and does not allow to keep the state in the interleaved form (i.e. [[u64; Self::PAR_SIZE]; PLEN]).

One potential option is to introduce keccak_backend="simd128/256/512" configuration options.

@aewag
Do you use the SIMD functions in practice? If you do, could you show us code which does it?

[tarcieri]

@newpavlov as a general rule SIMD backends are going to keep the state in SIMD registers between rounds, with an initial load step and at the end of a given number of rounds a store step which splits them back out into an array of states

[newpavlov]

@tarcieri
The portable SIMD backend still needs to be handled somehow, but I think this PR is mostly ready for review.

[newpavlov]

We could modify it to return a result (i.e. fn call_once<B: Backend>(self) -> Self::Output) and modify the Keccak methods accordingly, but I am not sure it's worth the trouble.

[tarcieri]

To me it would make more sense if the different state sizes and their backends were modeled as separate types, rather than listing them all out in a single trait/type. That's how we do things everywhere else that some algorithm/construction is implemented for different sizes.

I'm not sure it even makes sense to support this for any state size other than b=1600? XKCP doesn't have SIMD implementations for the other state sizes.

[newpavlov]

To me it would make more sense if the different state sizes and their backends were modeled as separate types, rather than listing them all out in a single trait/type.

We could do it, but it would result in a fair amount of somewhat annoying boilerplate. On the other hand, it would resolve the issue with the software fallback, since backends will be selected independently for each function.

I'm not sure it even makes sense to support this for any state size other than b=1600?

I am not aware about potential parallel uses for those, so maybe not. I was trying to future-proof the API and adopting the portable SIMD implementation for it looks simple enough.

I guess we could start with parallel support only for b=1600 and add other functions later if needed.

[newpavlov]

These methods are kept for consistency with the f/p1600 methods and to future-proof the API.

[tarcieri]

Not sure what's up with the commented out sections but having something in place for this seems good and I don't want to delay a release too much. If we get the API nailed down I can add e.g. SSSE3 and/or AVX2 later.

I'm also fine with keeping things infallible.

[newpavlov]

Not sure what's up with the commented out sections

It's mostly the portable SIMD stuff. I plan to introduce simd128/256/512 backends today or tomorrow as a replacement for those parts.