Server as p2p certificate authority

[termermc]

Right now, there is no certificate verification when doing p2p connections. Clients just accept any certificate, and p2p certs are generated on-the-fly. This is fine, unless there's someone interested in doing a MitM attack.

To solve this problem, MSG_TYPE_ADVERTISE_CONN_METHOD messages should include a public key that can be returned when a client request's a peer's methods with MSG_TYPE_GET_CLIENT_CONN_METHODS.

Each direct connection should be made with a DirectConnMethod struct that includes all the information about the method, including its certificate.

To maintain backwards compatibility, a client that tries to connect to a method without a certificate (advertised by an outdated client or relayed by an outdated server) will fall back to the old behavior of not verifying the certificate.

[termermc]

It might be useful to expose a different certificate for the same underlying P2P listeners per-server, for privacy. That could prevent a user from identifying users across servers.

The counterargument to this is that if you're exposing p2p connection methods, those will also be trackable across servers today. For example, if your public IP is listed as a connection method, that will be unique to you anyway. Disabling direct connections entirely will prevent all privacy leaks, both associated with p2p addresses and theoretical certificates.