When Rust derives Copy, Clone, Eq, PartialEq, etc. on a type with
`PhantomData<T>`, it adds a `T: Clone` etc. bound, regardless of whether `T` is
only ever used inside of the `PhantomData`. A better fix would be to fix the
derived bounds themselves, but in the meantime this works, even if it's
slightly ugly.
The `SpendAuth` test vectors were generated using
`FixedGenerators::SpendingKeyGenerator`, and the `Binding` test vectors
were generated using `FixedGenerators::ValueCommitmentRandomness`.
This ran into problems with Clone/Copy bounds -- it seems like the
derived impls require that the phantom type T also be Clone / Copy /
Debug for the type to be. This commit does a hacky fix that makes it
work for now, but it should be cleaned up later.
The motivation is as follows. The sealed trait pattern allows creating
a type-level equivalent of an enum: the trait corresponds to the enum
type and its implementors correspond to the enum variants; the `Sealed`
restriction ensures that there is a fixed set of enum variants.
In this picture, adding methods to the public trait corresponds to a
public method on an enum, while adding methods to the private trait
corresponds to a private method on an enum. This means that we can add
a method to get the basepoint (whose possible choices are enumerated by
SigType) and avoid having to do specialized impls.
This means that using a BindingSig as a SpendAuthSig or vice versa becomes a
compile error. Internally, we can share implementations, but having type
parameters and specialized impls means that the correct parameters can be
substituted in to whatever inner functions exist.