Create EncodingKey/DecodingKey from borrowed data

[uklotzde]

Avoid allocations by capturing borrowed data as Cow::Borrowed.

[uklotzde]

Creates conflicts with #483 that should be easy to resolve.

[arckoor]

So I very briefly looked at this, and while it seems fine in theory I don't quite understand the use case.
There is a legit argument in terms of allowing the user to manage secrets however they please, I admit I'm not a big fan of how the library does this currently.
I have considered instead of just doing a zeorize using something like secstr.
I suppose this PR would allow wrapping the secret in something like that and passing a slice via unsecure(), but imo the Cow completely negates that. For DER it seems like it mostly remains in the users hand, but for PEM it's owned because the PEM does need to be decoded first, and there is no one else to own the data. Which brings us back to the library managing the secret.

[uklotzde]

Use case: We store the owned, secret data separately and only expose it temporarily to jsonwebtoken when issuing and validating JWTs.

[arckoor]

I don't think this is a good way to solve the problem unfortunately, especially since it does nothing for people that use PEM
It adds lots of unnecessary complexity for other users (they suddenly need to manage their secrets themselves), and it prevents us from doing anything more interesting in terms of data storage for EncodingKey and DecodingKey in the future.
What I could rather imagine is a concept similar to CryptoProvider but for secrets, i.e. a SecretProvider. One that is plug-able by the end user, where the default one just uses a Vec<u8> and maybe zeroizes, and an application is free to register its own that uses secstr or whatever
Would that work for you?

[uklotzde]

Don't mind. This was just proposed as an optimization to avoid an unnecessary allocation. Performance is not an issue for us (yet).

The plugin/provider concept sounds reasonable and avoids to make an opinionated decision with new dependencies. Clients should be free to decide how and where they store their secrets. A default provider could be provided behind a feature flag for convenience.