Use rejection sampling for random point generation

[daxpedda]

This PR changes random point generation to use rejection sampling by de-serialization instead of deriving a point from a random scalar.

Fixes #1140.

[andrewwhitehead]

Wouldn't there be a modulo bias without reducing a field element from a larger random input?

[tarcieri]

@andrewwhitehead no, it's the other way around: reduction introduces a bias, and even a wide reduction has a minute bias. Rejection sampling is unbiased.

https://research.kudelskisecurity.com/2020/07/28/the-definitive-guide-to-modulo-bias-and-how-to-avoid-it/

[daxpedda]

Wouldn't there be a modulo bias without reducing a field element from a larger random input?

No, de-serialization actually declines field elements that don't fit the modulus.
(ed448-goldilocks still needs some fixes in that area)

[tarcieri]

I know I just stamped approve, but now I'm kind of noticing that perhaps this should be an inherent pub fn try_from_rng impl'd on AffinePoint, and then the ProjectivePoint impl could be:

Suggested change

	let mut bytes = FieldBytes::<C>::default();
	let mut sign = 0;
	loop {
	rng.try_fill_bytes(&mut bytes)?;
	rng.try_fill_bytes(core::array::from_mut(&mut sign))?;
	if let Some(point) =
	AffinePoint::decompress(&bytes, Choice::from(sign & 1)).into_option()
	{
	return Ok(point.into());
	}
	}
	AffinePoint::try_from_rng(rng).map(Into::into)

[daxpedda]

I agree, but don't we need a trait for that to implement it in primeorder?

[daxpedda]

Apparently not.
Working on it.

[daxpedda]

Done.

EdwardsPoint and DecafPoint still need a bit more work.
After this is merged I will do the necessary follow-up for EdwardsPoint in #1333.
Will make a PR for DecafPoint later.