Improve Hypernova folding tests

[federicobarbacovi]

The tests now only look at basic behaviour, they should be improved where possible. There might be some overlapping between the test suites.

We have three test suites:

• FoldingProver: checks:
  • (valid accumulator, valid instance) ---> valid accumulator
  • (invalid accumulator, valid instance) --> invalid accumulator; here invalid means that for one of the polys we have commit(p) != C, where C is the commitment stored in the accumulator. This is the only way in which the accumulator can be invalid, as the fact that p(challenge) = ev_p is checked by the sumcheck that converts an instance into an accumulator, and so can't be checked on prover side
• FoldingVerifier: checks:
  • (valid accumulator, valid instance) ---> valid accumulator
  • (valid accumulator, invalid instance) --> invalid accumulator, sumcheck to turn instance into accumulator fails. Here invalid instance means f(instance) != 0 where f is the UltraHonk relation
• Decider: checks:
  • (valid accumulator, valid instance) ---> valid accumulator
  • (invalid accumulator, valid instance) --> invalid accumulator; here invalid means commit(p) != C for one of the polys. Failure is caught by the sumcheck that batches two accumulators (in circuit) and by the decider (not in-circuit, the pairing point verification)
  • (valid accumulator, invalid instance) --> invalid accumulator; the failure is caught by the sumcheck turning the instance into an accumulator.
  • (valid accumulator, valid instance), tampered folded accumulator --> valid accumulator, but decider fails (not the circuit, the pairing point verification)

[federicobarbacovi]

The tests above refer to Hypernova as a folding scheme, so they cover what should be covered for a folding scheme. Many tests for our specifc usage of Hypernova have been added after this issue was created. Coverage is now good.