Vartime methods should return `Option` instead of `CtOption`

[tarcieri]

We have several methods that are advertised as variable-time which are returning CtOption instead of Option.

This is a bit suboptimal: CtOption eagerly evaluates its combinators, whereas Option uses lazy evaluation. It would generally be more efficient to use Option.

Perhaps a reason why this was the case originally was trouble converting from ConstCtOption to Option inside a const fn in the past, but there's now ctutils::CtOption::into_option_copied which can be used as a const fn, in cases where there's some shared code between the constant-time and non-constant-time versions of a function.

cc @andrewwhitehead @fjarri

[andrewwhitehead]

It does depend on why the method is vartime, in some cases it might still be constant time for self and it would make sense to return a CtOption.

[tarcieri]

Aah yes, that's true

[andrewwhitehead]

It might be cleaner and more ergonomic to return Checked<T> from the constant-time methods. With that, I think you could mostly hide CtOption from the public API. Checked could use a few helper methods in that case, like into_option and expect/expect_copied and maybe unwrap. For the vartime cases it seems like Option<T> might still be the best option, unless another CheckedVartime type was added.