Feat: securing gRPC HTTP connections

[D4ryl00]

We want to provide a gRPC client to React-Native to communicate with the Gnomobile service, which implements the gRPC server.
We have two choices:

1. Because we cannot directly support stream calls from React-Native to Go, we have to convert streams to unary calls. So we can write an RPC object in Typescript, named bridge, which converts stream calls to unary calls so we will be able to pass them in the native and Go parts. It looks like Berty does with the Bridge Service Client: berty bridge.
   This works fine but in a hacky way for mobile. In the future, we want to port the React-Native client to the desktop, so without native parts (Java, Swift), which will add some additional work to make it compatible.
2. We can use the new gRPC Web client that supports unary and stream calls natively. But the client works through HTTP connection, and our Go gRPC server doesn't implement a secure HTTP authentication.
   A solution is to determine if we can create a new transport that allows us to perform native binding still using that gRPC web client.

Because number 2 is a cleaner and future-proof way, we could implement a secure authentication to our Go gRPC server to enable us to use standard gRPC clients through HTTP connections, without the need of creating hacky transports for the clients.

[D4ryl00]

After further research, connect-web cannot use the default transport in react-native because Fetch API is not fully supported: https://github.com/connectrpc/examples-es/tree/main/react-native

The XHR replacement transport for react-native doesn't implement streams yet: https://github.com/connectrpc/examples-es/blob/main/react-native/custom-transport.ts

Also, connect-web seems to accept only TLS authentication, which is not the best for our use case: https://github.com/connectrpc/connect-es/blob/main/packages/connect-web/src/grpc-web-transport.ts#L88

[D4ryl00]

Using the Berty's handshake protocol for gRPC authentication checks all the boxes:

• The client must know the server's public key before the handshake. That could be returned by the initBridge function.
• This protocol protects from the man-in-the-middle over insecure channel.
• It generates secrets to crypt communications.