Initial support for TLS

[minghuaw]

An initial attempt to add TLS support for gRPC.

Motivation

#6

Solution

Two new features flags are added "rustls" and "native-tls" so that user can choose the preferred TLS implementation in the community. A new client/server example that uses "rustls" is added to showcase the usage.

Additionally, Cargo.lock is removed from the tracked files in git.

[CLAassistant]

All committers have signed the CLA.

[PureWhiteWu]

Wow! This is a really great pr to implement an important feature! Thanks very much for your contribution!

[PureWhiteWu]

Furthermore, I think we should still preserve the Cargo.lock, this is useful for cooperation, because everyone maintaining this project can have the same build environment and reproduce the build.

[minghuaw]

Furthermore, I think we should still preserve the Cargo.lock, this is useful for cooperation, because everyone maintaining this project can have the same build environment and reproduce the build.

I doubt this though. I personally do not remember other open source library crates doing the same thing. Plus, I have just looked through a few closed PRs, and seems like Cargo.lock appear quite frequently in the PRs. That doesn't sounds like it's "keeping the same build environment".

[minghuaw]

Which version of pilota and motore should be used? Trying to compile the examples but getting errors that afit and rpitit are not enabled in those two crates

Edit: Nvm, updated my nightly toolchain and this problem is gone. Should there be a minimum toolchain version somewhere though?

[PureWhiteWu]

I doubt this though. I personally do not remember other open source library crates doing the same thing. Plus, I have just looked through a few closed PRs, and seems like Cargo.lock appear quite frequently in the PRs. That doesn't sounds like it's "keeping the same build environment".

In fact, we have tried to remove the Cargo.lock before, but we encountered some problems, such as I have updated the dependency in my dev environment, but other people didn't, so after they pull the code, they will encounter compile failure, and may lead to extra communication cost.

[PureWhiteWu]

Should there be a minimum toolchain version somewhere though?

We are supposed to have a MSRV of 1.75 in the future. But for now, we recommend to use the latest nightly.

[minghuaw]

I doubt this though. I personally do not remember other open source library crates doing the same thing. Plus, I have just looked through a few closed PRs, and seems like Cargo.lock appear quite frequently in the PRs. That doesn't sounds like it's "keeping the same build environment".

In fact, we have tried to remove the Cargo.lock before, but we encountered some problems, such as I have updated the dependency in my dev environment, but other people didn't, so after they pull the code, they will encounter compile failure, and may lead to extra communication cost.

I still think there are better ways to get around this, but if that's really troubling for you, I am fine with tracking Cargo.lock with git (fixed in 6b9c8d5).

[PureWhiteWu]

LGTM，Thanks for your contribution!
@bobozhengsir @Millione PTAL

[PureWhiteWu]

Thanks again for your contribution!