Improve ergonomics on identity::Keypair

[drHuangMHT]

In #3350 we've made the decision to make Keypair opaque. But I think there's more to be done. Currently deprecating keypair variants makes it harder to know what's inside. You have to try those methods one by one to see what it is. This won't be a problem if you're not importing and exporting keys. Instead of trying out many different methods to get the key imported or exported(which is annoying), we can unify them into two with one responsible for importing(bytes to Keypair) and one for exporting(Keypair to bytes). Matching can be done internally instead of letting users handle this. Plus, it's not a piece of performance critical code.

[thomaseizinger]

We have to_protobuf_encoding which we could extend to also export other key types.

Two questions:

• Why do you need other keys than ed25519?
• Do you need the type for something else or just exporting?

[drHuangMHT]

When in doubt, less config options are better IMO.

Type Keypair has already abstracted some logic to eliminate the difference between those keys, they can be used as long as they're included in the variants. But we didn't further abstract the logic after we made the type opaque causing troubles when importing and exporting keys.
Please let me be honest, I'm losing patients now because I have been trying to convey my point for so long. It happened before but this time I really get upset. Maybe I should get the code running before opening a discussion about it.

[drHuangMHT]

Think think think how would other apps save their keys. If there are standards for those kinds of keys, they should point out what the key itself looks like. I believe the actual key does not vary with the application.

[drHuangMHT]

Let me summarize with an analogy. I'm working in a distribution center where I should put packages into different ports according to tags on both. Then the distribution center announced that they are trying to prevent packages from being put into wrong ports. They removed the tags on the ports leaving me to guess where the package should go to. I proposed that a sorting machine should be built between me and those ports, given that both the packages and ports have tags that can be matched by machines. Then the manager questioned why I'm using so many ports. Why? Because they are here, the distribution center claimed that they can handle those packages so they should be prepared. That's what is happening when importing keys.
I know not why you keep trying to drive the car off the lane. The two questions at the beginning are NOT related to implementation at all yet we still spend so much time digging into them.

[drHuangMHT]

I'll remain inactive for quite some time from now on because yesterday I blew up my physical server at dorm that is purchased using my parents' hard-earned money, the schoolwork is also coming at me. If I don't stop, I'll blow my self up, literally. I really don't know why I'm in such a situation.

[thomaseizinger]

Type Keypair has already abstracted some logic to eliminate the difference between those keys, they can be used as long as they're included in the variants. But we didn't further abstract the logic after we made the type opaque causing troubles when importing and exporting keys.

Once #3630 is implemented, any type of key can be serialized and thus exported and imported again. Is that sufficient for your usecase?

[drHuangMHT]

Also a pending draft PR that's probably worth noticing #2671.