Avoiding zero in bach muls

[codygunton]

As in the case of AztecProtocol/aztec-packages#5174, we sometimes encounter issues relating to our inability to handle scalar multiplication of EC points in the case where the scalar is 0. I believe: this could be fixed by simply checking whether z==0 before https://github.com/AztecProtocol/aztec-packages/blob/394a0e06928946c1c9eea1bdfec39269cb2d601a/barretenberg/cpp/src/barretenberg/ecc/groups/element_impl.hpp#L68, but we avoid this because of the cost of the check. Someone should determine whether this is really a concern, and if it is, we should identify some hot code paths and use a more robust method outside of those cases.

[ledwards2225]

The use of the ECCOpQueue::append_nonzero_ops method on all circuits is inadvertently creating an interesting test case. Since this method updates the op queue ONLY (ultra and raw ops) but NOT the ecc_op block in the circuit, the translator and ECCVM are operating on a different set of ops from that of the Ultra circuit / Honk prover / Merge protocol. Eventually this discrepancy should lead to a proof that fails to verify but we need to think more about exactly where this should happen.

[maramihali]

I think the issue of EccOpQueue::append_nonzero_ops not appending both ultra and eccvm ops was fixed.

[iakovenkos]

@suyash67 and @ledwards2225 seems this can be closed?