client: verify certificate host keys

[biao29]

Lets a client accept a server that proves its identity with an OpenSSH host
certificate instead of a bare key, so a fleet can be trusted through its CA
rather than through a fingerprint on every machine and every device.

Off by default. Preferred::host_key_certificates is empty unless a caller
fills it in, so no existing client changes what it advertises and no server
starts sending certificates to a client that has no idea who is allowed to have
signed them.

What changes

• Preferred::host_key_certificates: the certificate algorithms to advertise.
  A parallel list because Algorithm cannot represent one — it maps
  ssh-ed25519-cert-v01@openssh.com back to Ed25519, so a certificate placed
  in key would be advertised under the plain name and never negotiated.
• client::Handler::check_server_certificate, called instead of
  check_server_key when the server presented a certificate. It defaults to
  refusing: a client that has not been told which authorities it trusts cannot
  answer, and answering wrongly accepts any host whose operator can obtain a
  certificate from anyone at all.
• The client key exchange decodes a certificate when the blob is one, verifies
  the exchange signature with the key the certificate contains, and carries the
  certificate to the handler.

The part worth reviewing closely

The exchange hash now uses the blob the server actually sent, rather than
re-encoding the parsed key:

-    server_host_key.to_bytes()?.encode(&mut pubkey_vec)?;
+    server_host_key_blob.encode(&mut pubkey_vec)?;

For a plain key the two are identical. For a certificate the parsed form is
only the key inside it, so re-encoding hashes something the peer never sent —
and both sides of that comparison are computed locally, so the failure surfaces
as a bad signature with nothing on the wire to compare against.

The certificate's own signature is deliberately not checked here. That is a
question about trusted authorities, which only the handler can answer; verifying
the exchange with the contained key and vouching for the certificate are two
separate proofs, and collapsing them would accept a certificate nobody vouched
for.

Compatibility

Adding a field to Preferred breaks code that builds it literally rather than
with ..Default::default(). Two such literals in this crate are updated in the
second commit. Everything else is additive: a new defaulted trait method and a
new field.

Testing

cargo test -p russh --lib passes (152 tests). Exercised end to end against
OpenSSH sshd with HostCertificate configured and AuthorizedKeysFile none,
including the refusal path when the presenting authority is not one the client
was told about.

[Eugeny]

@all-contributors add @biao29 for code

[allcontributors]

@Eugeny

I've put up a pull request to add @biao29! 🎉

[Eugeny]

Had to add a few fixes so it's getting merged via #752

[oni303]

Would this also add support for servers to authenticate users that provide a signed certificate.
Please have a look at #641 we worked and tested quite a bit