Generating ed25519 key pair can produce key pairs not readable by parseKey

Hi. First off, thanks for your work on this library.

I'm seeing an issue where generateKeyPairSync can produce key pairs where either the private or public key cannot be successfully parsed by parseKey. This program reproduces the issue:

const utils = require('ssh2').utils;
while (true) {
  const keyPair = utils.generateKeyPairSync('ed25519');
  const parsedPublicKey = utils.parseKey(keyPair.public)
  if (parsedPublicKey instanceof Error) {
    throw parsedPublicKey;
  }
  const parsedPrivateKey = utils.parseKey(keyPair.private)
  if (parsedPrivateKey instanceof Error) {
    throw parsedPrivateKey;
  }
}

Commenting out the block that throws parsedPublicKey may be needed to quickly see cases where parsing the private key also generates an error.

I am not sure whether the issue is exactly in parsing the key or generating it, but I did notice that generateKeyPair will strip leading zero bytes from the public key, if the public key from the Node.js standard library starts with a zero:

https://github.com/mscdex/ssh2/blob/a56e70e68efd6a1c7e665c9a473eb68d25571a55/lib/keygen.js#L290-L297

My brief read of https://datatracker.ietf.org/doc/html/rfc8709#section-4 is that this can be incorrect if it strips the public key length to less than 32 bytes, but my understanding of the specification may be incorrect.

I did notice that feeding the generated keys with the stripped public keys to https://github.com/TritonDataCenter/node-sshpk parses successfully; I am not sure if that is an implementation detail of that library.

Start with lib/keygen.js around lines 290-297 and trace the utils.generateKeyPairSync and utils.parseKey entry points. Run the supplied reproduction repeatedly, compare the generated public-key lengths with RFC 8709 section 4, and verify that both generated keys remain parseable.