Support for async/await syntax in Rust SDK

[yoshd]

Is your feature request related to a problem? Please describe.
In Rust 1.39.0 the async/await syntax is stable, I suggest also supporting the async/await syntax in the Agones Rust SDK.

Relates to:
#1300
#1201

Describe the solution you'd like

Propose the following functions:

let sdk = agones::Sdk::new()?;

sdk.ready_async().await?;
sdk.set_label_async("test-label", "test-value").await?;
sdk.set_annotation_async("test-annotation", "test value").await?;
let gameserver = sdk.get_gameserver_async().await?;
// Other functions are similar...

Bump up some crate versions that the Rust SDK depends on.
The futures crate should be updated to version 0.3 or higher to support async/await syntax.
Also, the grpcio crate should be updated to version 0.6 or higher.

Describe alternatives you've considered
It might be possible to use the tonic proposed in #1300. But if we don't break the current API of the Rust SDK, it's easy to use a newer version of grpcio.

Additional context
By updating the grpcio version, #1201 may also be solved.

[markmandel]

Not necessarily against this idea, but curious what we are looking to gain by adding async functions?

Just figuring, it means we have to do blocking + async for every API surface for Rust going forward, and that will increase maintenance requirements. Just a thought.

Also - do we need to make sure it works for both Tokio, std-async and any other async engine -- or are we choosing one over another?

[yoshd]

Not necessarily against this idea, but curious what we are looking to gain by adding async functions?

What I can easily think of is seamlessly implementing the Agones SDK for game server applications running on an asynchronous runtime.

Just figuring, it means we have to do blocking + async for every API surface for Rust going forward, and that will increase maintenance requirements. Just a thought.

You're right.
However, since the SDK is a simple gRPC wrapper at the moment, I don't think the maintenance cost is too high.
But if the number of functions increases in the future, maintenance requirements may increase...

Also - do we need to make sure it works for both Tokio, std-async and any other async engine -- or are we choosing one over another?

Ideally, I think it should work for both of the above.
However, if this uses tonic, it must use Tokio.
I think that grpc-rs has a core implementation of C++, so I don't think there are any restrictions on runtime, but I have not actually verified it.