Integrate upstream hostaddr/load balancing support

[benesch]

This is more flexible than our previous approach to allowing the TLS verify host to be overridden. In particular, users can specify multiple IPs to try for the same host, e.g.:

Config::new()
  .host("my-pg-server")
  .hostaddr(1.2.3.1)
  .host("my-pg-server")
  .hostaddr(1.2.3.2)
  .host("my-pg-server")
  .hostaddr(1.2.3.3)

[rjobanp]

I have some feedback on the API change but the rest of the code logic & tests LGTM

[rjobanp]

this API change feels a little brittle/confusing to me and I'm wondering if we could rework it to be more straightforward somehow. It just seems awkward that there is in implicit order-based mapping between two separate parameters. Is there a reason not to change the semantics of the host parameter itself?

One idea would be to use : to specify host->IP mapping in the host parameter, so you could do something like this:

host=host1:127.0.0.1:127.0.0.2,host2:127.0.0.3,host3

specifying that host1 maps to the first two IPs, and host2 maps to the 3rd, and host3 should be resolved itself

[rjobanp]

similar to the comment on the string parameters, it seems that it would be a lot cleaner to add a new enum type to the Host definition that tied together the mappings more clearly:

/// A host specification.
#[derive(Debug, Clone, PartialEq, Eq)]
pub enum Host {
    /// A TCP hostname.
    Tcp(String),
    /// A resolved TCP hostname and associated IP addresses to use.
    /// The hostname is only used when the SSL mode requires host verification.
    ResolvedTcp { host: String, ips: Vec<String> },
    /// A path to a directory containing the server's Unix socket.
    ///
    /// This variant is only available on Unix platforms.
    #[cfg(unix)]
    Unix(PathBuf),
}

[benesch]

Oh, sorry, I should have mentioned that these API changes come from upstream: sfackler#945

I agree that the order dependency is confusing, but that comes from libpq (https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-MULTIPLE-HOSTS), and rust-postgres strives to be exactly compatible with libpq's connection strings.

[rjobanp]

Ah that makes sense! Thanks for clarifying