crypto: accept ed25519 priv key as a value type

[areknoster]

Since underlying type is []byte, the ed25519 key is generally passed as a value, not a pointer.

In particular, nowhere in std crypto package it is, nor any common parsing functions returns it this way.
The test itself shows the issue: whereas all other keys are passed as they are got from their respective generators,
ed25519 needs additional pointer retrieval. Also the behaviour is inconsistent, since in function PubKeyToStdKey in the case for Ed25519 a value to type with underlying []byte is returned, not a pointer.

This is a breaking change though, so if the lib is considered stable, the previous method should be deprecated and new one created.

[marten-seemann]

Looks reasonable to me. The only thing I'd be worried about is that this might break existing code.
I can't see any use of these two functions across the PL stack though.

@vyzo, wdyt?

[vyzo]

sounds reasonable, but lets keep compatibility and also accept pointers given by the user.

[areknoster]

Ok, will adjust, so that both forms are accepted

[areknoster]

Adjusted for backward compatibility. In PrivKeyToStdKey solution with adding additional switch case is not possible, since we're returning the pointer value, so I propose deprecation and new PrivKeyToStdCompatKey function

[Stebalien]

Why not just accept both in a single function?

[areknoster]

Sry for late reply, @Stebalien the changes I propose here in current version do extend KeyPairFromStdKey function to accept value type. I just realised, that I forgot to adjust commit and PR title to communicate the change, which I've just done.

As for the PrivKeyToStdKey, we can't adjust it without breaking changes (pointer to ed25519 priv key is returned), thus I propose to deprecate and have a new one in place.

[BigLep]

2022-08-26 triage note: Closing this at this point since it has been 8 months and it hasn't been merged yet. If it is still critical, please go ahead and open a PR in libp2p/go-libp2p since this repo is now archived.