Review Rust gRPC ecosystem for Rust SDK

[markmandel]

Context:
#1202 (comment)

The current Rust gRPC library has some issues around SSL, and the Rust ecosystem has changed a bit in the last while. We should review it, and see if it's worth switching out the underlying gRPC implementation -- without changing the Agones client SDK surface.

https://github.com/hyperium/tonic is looking like a forerunner from all reports, but apparently we might want to wait for a 0.2 release for the api surface to stabilise.

[Jake-Shadle]

Sorry for jumping the gun with #2112, I hadn't seen this issue before I started that work. Anyways, here are the pros/cons of switching from grpcio to tonic, as I see them.

Pros

• Tonic is rust native, meaning there are no additional dependencies beyond cargo/rustc needed to build the rust sdk now (no cmake, no go)
• While there is some C/asm code that will be compiled if TLS features are enabled, tonic uses rustls for its TLS implementation so there is no annoying dependency on openssl, making it easier to cross compile.
• Tonic is part of the tokio ecosystem, which is the "standard" async runtime in the the wider rust ecosystem, meaning the rust sdk will now generally slot in to people's projects more seamlessly, rather than adding an additional GRPC/network stack to their application
• Rust code is generated from protocols at buildtime and not checked in, which means it's generally easier to consume and make contributions to

Cons

• Rust code is generated from protocols at buildtime and not checked in, which requires additional build dependencies like prost-build which are quite heavy, and requires the protocol files be copied adjacent to the rust sdk as cargo won't allow packaging crates from files above the cargo manifest directory
• Tonic is async only, so you need to wrap sdk method calls in other code if you want to call them from a non-async context
• Tonic clients are cloneable, but not internally mutable, so public methods need to be &mut self, otherwise you would need to take a mutex lock for every method (wasteful) or internally clone for each method (also wasteful).

[markmandel]

@Jake-Shadle do we have any concerns around tying our API to the Tokio async ecosystem?

If someone wanted to use async-std for example, would that be an issue for them?

[Jake-Shadle]

Not particularly, it does mean an application would have 2 futures reactors/executors, but once you have created the future for either an async-std or tokio you can execute it on whichever reactor you want to use. So I believe the worst thing would be if some project doesn't already have a dependency on tokio at all, but wants to use agones, but honestly that seems like it would be an extremely rare case IME.

[markmandel]

So I believe the worst thing would be if some project doesn't already have a dependency on tokio at all, but wants to use agones, but honestly that seems like it would be an extremely rare case IME.

Yeah that doesn't bother me either. Sound good.

The biggest issue then is just making sure that our compliance tests still pass, and we maintain backward compatibility I think.

[markmandel]

Oh, and we need to update our rust examples too 😄

[Jake-Shadle]

I think #2112 addresses all of the Rust code already? Or at least, CI passes now after converting the examples and matching the previous behavior (from the perspective of the tests).