feat: split merge into recursive verification and proving

[ledwards2225]

ClientIvc/AztecIvc originally had a single method accumulate(circuit) which did two things under the hood: 1) append recursive PG/merge verifiers, and 2) perform the prover work for PG/merge. To facilitate the new noir-bb interface that Cody and I have designed, we need to be able to perform these two operations separately. This PR sets the stage for that by re-expressing the accumulate() method of AztecIvc in terms of two new methods: complete_kernel_circuit_logic() and execute_accumulation_prover().

The bulk of the work in doing this was similarly splitting up the method goblin.merge() which performs both recursive verification for the previous merge proof and merge proving for the circuit being accumulated. We now have individual methods goblin.prove_merge() and goblin.verify_merge() (which have been integrated into AztecIvc only). Merge proofs are added to a merge_verification_queue as they are created, which occurs on every accumulation round. When we get to a kernel we recursively verify each proof then empty the queue. On the first kernel there is a single merge proof to verify and in subsequent kernels there are two.

closes AztecProtocol/barretenberg#1063

[ledwards2225]

Performing two recursive merge verifiers in one circuit bumps this just beyond the previous limit

[ledwards2225]

I looked into making this more robust but its already as good as it can be without making the logic much more complicated. The circuits created here are just over a power-of-two limit so the amount we can add to them is maximized. If recursive verification gets more expensive then this might go over the limit again but that's just the way it is.

[AztecBot]

⚠️ Performance Alert ⚠️

Possible performance regression was detected for benchmark 'C++ Benchmark'.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.05.

Benchmark suite	Current: d671dbf	Previous: 5b9920f	Ratio
nativeconstruct_proof_ultrahonk_power_of_2/20	5002.010857000002 ms/iter	4747.736794999994 ms/iter	1.05

This comment was automatically generated by workflow using github-action-benchmark.

CC: @ludamad @codygunton

[lucasxia01]

Looks good!

[lucasxia01]

when is this function used?

[lucasxia01]

in client ivc I guess? is the plan that aztec ivc replaces client ivc at some point?

[ledwards2225]

Yeah the plan is definitely that AztecIvc replaces ClientIvc as the IVC scheme used for aztec but it's not totally clear whether ClientIvc should go away or not. It might still have some use as a more general IVC scheme for noir or something