feat: introduce constraint blueprints. improve memory usage, enables custom gates and group of constraints

[gbotrel]

Warning: fat PR. See #602 for context.

Breaking changes

For circuit builders / developers: none.

constraint package is impacted; in particular, since ConstraintSystem object is now the same for R1CS / Plonkish, methods AddConstraint and GetConstraints are now AddR1C (resp AddSparseR1C) and GetR1Cs. Signature is slightly modified (see Example in _test.go files in constraint/).

TLDR

Essentially the goal of this PR is to minimize the memory footprint of compiled constraint systems (for both R1CS and Plonkish). The core idea is instead of storing a flat list of constraint, to store a list of Instruction which points to some calldata enabling a Blueprint to "compress" (during compile time) a constraint into calldata and to "decompress" it during solving (or setup for zk backends).
So for a (simple) example a plonk gate doing qL * xa + qR * xb + qO * xc == 0 will just store these coefficients / wire ids (and not the unused one like qM or qC).

Additionally did refactor the SparseR1C structure to follow qLxa... notation.

The blueprint solving arithmetic is done using the same mechanism than in the frontend; we allocate (on the stack) a [6]uint64 and do field ops on that. I had a shot at generic again but it's just too ugly / adds barrier / performance & memory issues.

TODO

• Serialization of blueprint is just a mvp, might be the right path, might be not. (ie we could have a registry like hints or something else).
• Unplugged CheckUnconstrainedWires
• Future PR: add "blocks of constraints" to further minimize memory footprint (see feat: lazify the constraints repeatable used; added poseidon for test #549 )
• perf: investigate, if needed could have "specialized blueprints" for some frequent hints like binary decomposition & such to store coefficient references once.

Perf Status;

comparing the emulated bn254 pairing on develop vs on this branch:
regression on R1CS solver (+11% slower). all the rest (compile / solving time for both types) is faster / less greedy.

-56% for memory r1cs
-36% for memory scs 

(this is without block of constraints / optimized blueprints for hints, etc)

impacts on perf of the compiler & solver:

benchmark                            old ns/op       new ns/op       delta
BenchmarkPairing/compile_scs-10      23655591709     17436404667     -26.29%
BenchmarkPairing/solve_scs-10        2588727583      2285032250      -11.73%
BenchmarkPairing/compile_r1cs-10     20717499042     9739011416      -52.99%
BenchmarkPairing/solve_r1cs-10       1199609958      1333357208      +11.15%

benchmark                            old allocs     new allocs     delta
BenchmarkPairing/compile_scs-10      307815721      206326052      -32.97%
BenchmarkPairing/solve_scs-10        19024494       9639805        -49.33%
BenchmarkPairing/compile_r1cs-10     194413859      118428787      -39.08%
BenchmarkPairing/solve_r1cs-10       19024495       9643794        -49.31%

benchmark                            old bytes       new bytes       delta
BenchmarkPairing/compile_scs-10      29156295160     17976918504     -38.34%
BenchmarkPairing/solve_scs-10        2885155400      2522378920      -12.57%
BenchmarkPairing/compile_r1cs-10     34127280208     27831332584     -18.45%
BenchmarkPairing/solve_r1cs-10       1337235808      979406728       -26.76%

[gbotrel]

note: trying to have R1C and Hint blueprint implement solve to recover from solver perf regression.

[ivokub]

It is a big PR and I tried to find something, but imo the implementation is very straightforward. Everything makes sense.

I tried to find any typos or problems, but couldn't find any. But in any case I would still let it settle one develop for a bit just to edge off any potential bugs.

[ivokub]

Should check no duplicate blueprints?

[gbotrel]

probably... but do you compare the object type or the object itself? so far our blueprint are stateless, but I'm thinking a specialized hint blueprint that store in the struct list of powers of 2 coeff IDs would be interesting.
Or a blue print that stores the params for MiMC permutation. (ie no need to store these in the constraint related to that).