Should `PaddingScheme` and `SignatureScheme` be object safe?

[tarcieri]

In #260 it was pointed out that PaddingScheme isn't object safe.

I think the purpose of these traits is to provide runtime dynamism around key usages, which makes the lack of object safety a bit problematic.

Especially with #259 complementing the existing signature-related SigningKey/VerifyingKey types with nice monomorphic purpose-dedicated encryption-related counterparts, that would make for a nice split between those providing a performance-oriented, type-safe monomorphic API, and PaddingScheme/SignatureScheme could evolve to focus on runtime dynamism.

Making that work would involve quite a bit of refactoring, getting rid of the generic parameters on the methods and replacing them with dyn Trait, namely for the PrivateKey, PublicKey, and CryptoRngCore traits. This would in turn require finding some way to make the PrivateKey and PublicKey traits object safe. At that point, we might consider trying to recombine the four traits (PaddingScheme, SignatureScheme, PublicKey, PrivateKey) somehow.

[tarcieri]

One way I could see a refactor working is reversing the relationship between the *Key and *Scheme traits so that methods of the *Key traits accept the *Scheme traits as arguments.

This would make the *Scheme traits only responsible for constructing padded messages that the *Key traits then act on. That would make it a lot easier for the *Scheme traits to be object safe, and also minimize their responsibilities.

[tarcieri]

I experimented with this in #310, however all methods of these traits need to move out of self, which means they can't be object safe.

So closing as this won't work, unless we redesign the traits.