Upgrade tonic to 0.7

This is a breaking change

TODO: ~~They've made it harder to break TLS so for now I've just commented out the test that uses that feature. Probably for the best this way~~

I've deleted these tests. We should find a way to test them properly at some point but for now I think it's fine

This PR does the following: Adds changelog for 0.3.0 release. Updates tonic to 0.6 and prost to 0.9. Removes blip comment . Updates to rust 2021 edition

Move openssl crate to dev-dependencis so that it does not introduce an unnecessary OpenSSL dependency for projects that do not need or want it; for example, projects that use RustTLS over OpenSSL.

This PR tries to address the following:

• Make sure that the hostname part of the ServiceDefinition is valid by making the fields private and force constructing it through from_parts that includes the validation.
• Allow users to resolve the ServiceDefinition once before building the LoadBalancedChannel through a new method build_and_resolve that does the same as channel only that it will only succeed if a call to LookupService::resolve_service_endpoints is successful.

Closes #20.

Motivations

The service probe loop appears to log and ignore errors while running. This seems fine while the service is running, but at startup, it could be an indication that the ServiceDefinition has an invalid hostname (e.g., has a typo). Some callers might prefer to panic in that situation so deployment systems are immediately aware of a problem instead of just reporting nothing resolved via metrics.

Solution

When constructing a LoadBalancedChannel, the code should wait for an initial resolution of the provided ServiceDefinition to succeed before returning the LoadBalancedChannel. This has the benefit of (1) finding invalid DNS names immediately (and allowing the program to exit immediately); and (2) ensures that LoadBalancedChannel has an initial non-empty set of endpoints to use before the program enters application code.

Alternatives

An alternative would be for callers to access the current set of endpoints and wait with a timeout until there are one or more endpoints. If no endpoints are resolved by the timeout, then a caller could error exit or alert. I don't know offhand whether Channel supports something like this.

Conversion from prost_types::Timestamp to SystemTime can cause an overflow and panic

| Details | | | ------------------- | ---------------------------------------------- | | Package | prost-types | | Version | 0.7.0 | | URL | https://github.com/tokio-rs/prost/issues/438 | | Date | 2021-07-08 | | Patched versions | >=0.8.0 |

Affected versions of this crate contained a bug in which untrusted input could cause an overflow and panic when converting a Timestamp to SystemTime.

It is recommended to upgrade to prost-types v0.8 and switch the usage of From<Timestamp> for SystemTime to TryFrom<Timestamp> for SystemTime.

See #438 for more information.

See advisory page for additional details.

Our ServiceDefinition cannot be processed by DnsResolver, so LoadBalancedChannelBuilder::new_with_service will always a Err and cannot apply lookup_service later.

It allows LoadBalancedChannel to leverage all tower's external machinery (e.g. ServiceExt) and, thanks to tonic, we get a tonic::GrpcService implementation for free [not a breaking change, thanks to that].

Add a builder method to allow users to ignore the LoadBalancedChannelBuilder type (or, at least, not having to import it directly). Edit examples to use the new method (and shorten them to avoid a horizontal scrollbar on docs.rs).

Bug description

Symptoms

1. GRPC requests are taking too long to time out when Kubernetes network policies are misconfigured.
2. The connection_timeout_is_not_fatal test takes ~75 seconds to finish.

Well-configured timeouts are important for system stability. Requests which take too long can hog resources and block other work from happening.

Causes

I can see two separate timeout problems:

1. DNS resolution – when ResolutionStrategy::Lazy is used, there is currently no way to apply a timeout just for DNS resolution. If DNS never resolves, requests never complete.
2. TCP connection – there is currently no way to set a connection timeout. On my machine, the socket seems to time out after ~75s. Even when we do set a connection timeout, tonic doesn't use it!

To Reproduce

For the TCP connection timeout, just run the tests. I'll supply a test for lazy DNS resolution timeouts in a separate PR.

Expected behavior

Ability to control timeouts for TCP connections and DNS resolution.

Environment

• OS: MacOS
• Rust version: rustc 1.65.0 (897e37553 2022-11-02)

Additional context

Solutions

The TCP connection timeout is simpler to solve (though I will admit took me a long time to find): we just need to set connect_timeout in the right places. First, topic doesn't respect connect_timeout, which will be fixed by this PR. When that is merged, we can create our own connect_timeout option on top of it (PR incoming).

DNS resolution is harder. There are currently two options:

1. Lazy resolution seems to be the default, but it also seems very hard to put a timeout around (at least, I can't think of a way!). It's possible to put an overall timeout around every request in the application, but this is 1. overly broad and 2. error-prone. It's very easy to forget or simply not know that it's needed ("why don't the other timeouts take care of it?").
2. Eager resolution has a timeout option. In practice, using this will probably mean doing DNS resolution on service startup, when the LoadBalancedChannel is created. This might be a good thing, preventing services from successfully starting when DNS would never resolve.

Of the two, I think we should favour Eager resolution, and consider changing the default to this.

However, we might want a third option: Active lazy resolution (for want of a better name). Lazy resolution is currently passive, as in it happens in the background on a schedule. It is never actively called in the request flow, which is why it's hard to put a timeout around. Instead, could we implement something which actively calls probe_once() (with a timeout!) as part of the first request (or alternatively when GrpcServiceProbe.endpoints is empty)? This could give us lazy DNS resolution, but with timeouts.

Addresses #31. Adds a new EndpointMiddleware trait and adds the with_endpoint_layer method to the LoadBalancedChannelBuilder. These middlewares are invoked on every SocketAddr that the lookup service discovers.

Usage:

let load_balanced_channel = LoadBalancedChannel::builder(("www.test.com", 5000))
        // set the concurrency limit for the endpoint
        .with_endpoint_layer(|endpoint: Endpoint| Some(endpoint.concurrency_limit(1)))
        // set the user agent for the endpoint
        .with_endpoint_layer(|endpoint: Endpoint| {
            endpoint.user_agent("my ginepro client").ok()
        })
        .channel()
        .await
        .unwrap();

Motivations

tonic's Endpoint type has many configurable parameters, for example keep_alive_interval

ginepro internally constructs Endpoint instances from socket addresses, and then applies some limited configuration values (like tls and timeout), but otherwise most settings remain the default.

Solution

It's probably not practical or ergonomic to specify every configuration value in ginepro's API; however it would be useful if the library could accept something like a Fn(SocketAddr) -> Result<Endpoint, SomeError> so that the user could configure an endpoint while the library handles stuff like periodic dns lookups