Fix: Bandersnatch GLV scalar multiplication

[yelhousni]

Description

Fixes #268

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)

How has this been tested?

TestCurve for Bandersnatch pass when using scalarMulGLV.

How has this been benchmarked?

Bandersnatch in R1CS:
2-bit windowed double-and-add: 3,314
GLV: 2,735
Bandersnatch in SCS:
2-bit windowed double-and-add: 5,991
GLV: 6,077

So the GLV saves 579 r1cs but adds 86 scs, which is because of the non-native scalar decomposition check. In this PR we use GLV only if endomorphism + R1CS.

Checklist:

• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• I did not modify files generated from templates
• golangci-lint does not output errors locally
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[gbotrel]

A remark, that probably applies to other neighbor pacakges;

I checked the call graph to see how it is tested, and it seems we just test with testData --> with random scalars.

Should we add some edge cases tests ? (i.e. scalar at 0, p-1, 1, ...),

[yelhousni]

A remark, that probably applies to other neighbor pacakges;

I checked the call graph to see how it is tested, and it seems we just test with testData --> with random scalars.

Should we add some edge cases tests ? (i.e. scalar at 0, p-1, 1, ...),

Yes indeed we should test edge cases. We already do so for emulated and native SW packages. Here it should be easier because formulas are complete.

[ivokub]

Looks perfect! I only added some comments what my local linter mentioned (unused arguments in methods).

[ivokub]

Looks good again. Maybe we should add a comment to the Curve interface that the methods ScalarMul, Add etc. do not check that point is on the curve.

For the future, it would be nice to also implement this - #1159. There was actually a discussion related to it just recently - #1292