chore!: change ec_add to unsafe implementation (but much better perf)

[guipublic]

Use unconditional_add for ec_add ACIR opcode.
This improves a lot the performance of the opcode, but also makes it unsafe.
I keep the PR as draft until aztec packages are sync with Noir PR noir-lang/noir#5858 which adds the checks in the stdlib function.
The unsafe version can then be used when we know the inputs are valid (for instance if they come from a previous add).
n.b.: the real performance boost will happen when we will be able to use the unsafe version.

[github-actions]

Changes to circuit sizes

Generated at commit: a3c66b78382216dcff87ca2e75c514874aeccb1c, compared to commit: 982a04e8021ec88b178ea05fdebb7193998cde38

🧾 Summary (100% most significant diffs)

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
private_kernel_reset_tiny	0 ➖	0.00%	-4 ✅	-0.01%
private_kernel_reset_small	0 ➖	0.00%	-8 ✅	-0.01%
private_kernel_reset_medium	0 ➖	0.00%	-16 ✅	-0.01%
private_kernel_reset_big	0 ➖	0.00%	-32 ✅	-0.01%
private_kernel_reset	0 ➖	0.00%	-64 ✅	-0.01%
private_kernel_reset_full_inner	0 ➖	0.00%	-64 ✅	-0.01%

---

Full diff report 👇

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
private_kernel_reset_tiny	35,560 (0)	0.00%	76,374 (-4)	-0.01%
private_kernel_reset_small	39,387 (0)	0.00%	102,743 (-8)	-0.01%
private_kernel_reset_medium	47,044 (0)	0.00%	155,660 (-16)	-0.01%
private_kernel_reset_big	62,353 (0)	0.00%	261,697 (-32)	-0.01%
private_kernel_reset	92,596 (0)	0.00%	472,771 (-64)	-0.01%
private_kernel_reset_full_inner	85,690 (0)	0.00%	443,083 (-64)	-0.01%

[zac-williamson]

From this comment it looks like the ACIR representation of an ecc point doesn't allow for a point at infinity?

What happens if I have two constant points, A and B where A = -B, and I compute A+B in noir? Is the compiler clever enough to return a point at infinity, or will the compiler cause the current code path (i.e. acir_format::create_ec_add_constraint) to be executed?

If it's the latter then I think it's better if we throw an error for the case where infinite.is_constant() is triggered, because the alternative is weird undefined behavior. If we're planning to fix the ACIR serialization in the near term we can skip, but if we forget about this issue it will cause us problems in the future because, if I understand correctly, the current implementation produces either undefined behavior or underconstrained code (i.e. the case where we add a constant point with its inverse)

[zac-williamson]

pedantic point: if infinite is defined as a bool_ct then we don't need to assume input_infinite is boolean - the bool_ct constructor will explicitly add a boolean gate.