Use optimized algorithm to check for Edwards torsion-freeness

[daxpedda]

The check if an Edwards point is torsion-free involves a scalar multiplication and is therefor quite expensive. This PR implements the algorithm from "Point-Halving and Subgroup Membership in Twisted Edwards Curves" to significantly reduce the computational requirements.

Ed448/decompress        time:   [116.51 µs 116.72 µs 116.90 µs]
                        change: [−76.218% −76.179% −76.147%] (p = 0.00 < 0.05)
                        Performance has improved.

[daxpedda]

I'm not sure what the is_on_curve() here really does. We reduce the y-coordinate and derive the x-coordinate, so I believe we always end up with a point that is on the curve.

Additionally, why do we require torsion-freeness on points in the first place? I think this should be optional and not enforced by the default decompress() function.

[tarcieri]

I'm not sure what the is_on_curve() here really does. We reduce the y-coordinate and derive the x-coordinate, so I believe we always end up with a point that is on the curve.

Yes, ideally points that aren't on the curve are unrepresentable, because the constructors be it via decompression or validating that a given set of affine coordinates are valid solutions to the curve equation always ensure a valid curve point.

Ideally if such a function exists you shouldn't need to make an invalid curve point first in order to check it! Rather the check can be implemented as a constructor which returns a point type only if the coordinates are valid.

[daxpedda]

I did go ahead and remove both checks, is_on_curve() and is_torsion_free(), in #1336.

[tarcieri]

Re: constructors that check affine coordinates, here's an issue for that for curve25519-dalek if you'd like to coordinate on APIs: dalek-cryptography/curve25519-dalek#817