Fix the missing parallel feature flag for ark-serialize

[weikengchen]

Description

This appears to be the blocker for a number of PRs since the latest test no longer allows a feature that is not declared in the Cargo.toml.

---

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.
• Re-reviewed Files changed in the GitHub PR explorer

N/A:

• Wrote unit tests
• Updated relevant documentation in the code
• Added a relevant changelog entry to the Pending section in CHANGELOG.md

[weikengchen]

Actually this is not as easy as I think: the problem is that we also implement Valid for things like Rc, but such structure is not "sendable".

[weikengchen]

Should we comment out the current parallel implementation then? The problem seems to be as follows: parallel check always requires the elements to be sendable to other threads, and therefore this places a limitation

[Pratyush]

This is a problem introduced by #811. I would rather that we revert the part there with removes Valid: Send instead of giving up on parallel check

[weikengchen]

I made an edit---now it has a different implementation.

Since all the batch_check requests would be reduced to the base primitives, and many trivial data structures may not benefit from parallel check:

• now, the parallel check is not going to be applied to Valid in general
• the base primitive needs to opt-in to accept parallel check
• now, only EC points and pairing element are opted in

[weikengchen]

limitation of the current implementation: it copies. This is due to the argument being "Impl Iterator" and you cannot make it parallelizable without first pulling all the elements out from the iterator.

The good thing, however, is that for EC points and pairing, such copying is usually worthy.

[Pratyush]

Why does the par_bridge solution not work here?

[mmagician]

ParallelBridge is implemented for Iterator + Send. We no longer have Send bound on batch here. So we'd need to put an explicit bound: batch: impl Iterator<Item = &'a T> + Send, but this propagates all the way up to Valid, and would in turn lead to two definitions of batch_check:

    #[cfg(feature = "parallel")]
    fn batch_check<'a>(batch: impl Iterator<Item = &'a Self> + ParallelBridge)...

    #[cfg(not(feature = "parallel"))]
    fn batch_check<'a>(batch: impl Iterator<Item = &'a Self>) ...