Please support client certificate identification for RPC/gRPC/Websocket access

[gilbahat]

Summary

Support client certificates as a method to identify the relay to RPC/gRPC/Websocket endpoints. This improved system security and stability by allowing the usage of private RPC endpoints for relaying, decreasing the effectiveness of an attack on the RPC endpoints.

Problem Definition

When operating a relay, it makes sense to provide it with private access to private RPC endpoints to protect the relaying from failure of the RPC nodes, or a directed attack.
Client certificates is the best such measure given that both HTTPS and gRPC need to be supported.

Proposal

Add two optional configuration fields to the chain configuration: client_certificate_pem and client_certificate_key.
the value of the first should be a filesystem path pointing to a PEM-encoded certificate file
the value of the second should be a filesystem path pointing to a PEM-encoded private key file with no password

the contents of these files should be validated and hermes should fail to start if they are not PEM files, passworded, mismatched, or unsupported by SSL libraries after decoding.

When initializing the HTTPS and GRPC clients, the certificate and key data should be passed as parameters to the clients, as per those clients' documentation.

Acceptance Criteria

This feature can be deemed complete once a trio of RPC-GRPC-WebSocket endpoints configured for client certificate identification is successfully used by Hermes.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate milestone (priority) applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[romac]

At the moment, we don't have the bandwidth to work on this, but would gladly accept a PR for it.

May I also that instead of having two options, let's group them both under a single client_certificate option, like so:

client_certificate = { pem = "...", key = "..." }