basic gRPC support

[yusefnapora]

This adds a subproject named rpc that defines some gRPC types and a simple service. The only functional method of the service is listCanonicals, which returns a list of all canonicals in the graph.

There's some awkward duplication of our domain types here; the Types.proto file basically redefines the various types from io.mediachain.Types as protobuf messages. I put some conversions to/from the gRPC types in io.mediachain.rpc.TypeConversions, so you can say e.g. someCanonical.toRPC to create an instance of the gRPC generated case class from a Canonical.

I also put in some definitions for Node, Edge and Graph types, but those are mostly "thinking out loud" about what a subgraph might look like encoded with protobufs.

You can run the server with sbt "project rpc" "runMain io.mediachain.rpc.LSpaceServer" and the client with sbt "project rpc" "runMain io.mediachain.rpc.client.LSpaceClient"

[yusefnapora]

BTW, the protobuf types are missing signatures & hashes, since I just wanted to get something basic up. Also, the LSpaceServer needs a .env setup with orientdb url and credentials, or it'll throw on startup.

We should also probably spend a minute figuring out whether this is worth pursuing further, since there's no browser support for gRPC (according to the FAQ, which I kind of wish I'd read yesterday...)

[parkan]

So the way we used thrift/spindle at 4sq was this:

• thrift definitions are the source of truth
• scala case classes, python classes and javascript objects generated from the thrift
• non-trivial accessors etc are mixed into the generated case classes (not 100% on how exactly this worked but can look)
• mongodb "schemas" are also generated from the thrift so you can specify stuff like indexes in there
• thrift serialization is used to write HFiles and maaaybe some client RPC
• webapp/other clients uses JSON transport that's loosely related to the thrift schema

This is nice for a polyglot environment but definitely very complex. Also note that even at this level we weren't using binary transport.

We should try to identify exactly the properties we want from the API and consider whether using these fancy libs is required. I suspect that ad-hoc serialized JSON can probably get us quite far.

(Thrift also ends up creating a ton of legacy cruft in your definitions if there's a lot of schema changes because of how compatibility works, not sure about protobuf)

[parkan]

given that most of these changes are in rpc/ and Build is unlikely to diverge a lot, I'm ok just parking this in a PR for now