Deprecate sslmode in favor of user and implementation configured policies.

[commonism]

I'm having issues getting SSL certificate verification to fail - even when using self signed certificates, different hostnames, or passing a random root ca.
Therefore I think it is safe to assume SSL certificate verification is broken.

ssl.wrap_socket does not verify the hostname, ssl.match_hostname is not used in the code.

And - the sslmode keywords differ from postgresql sslmode keywords, having at least "verify-full" would be good.

[jwp]

I don't recall "verify-full" being around when I wrote it. Also, I don't believe certificate verification had a documented interface (Python's built-in ssl module) when I wrote it as well.

[esran]

Postgres also has verify-ca for sslmode which should be included in support.

[jwp]

Looks like recent ssl versions perform at least one level of certificate verification. With libpq, the entire chain is checked according to https://www.postgresql.org/docs/current/libpq-ssl.html#LIBQ-SSL-CERTIFICATES

I think the future of sslmode in py-postgresql is deprecation.

Mimicking libpq's connect behavior was one of the more painful features to implement and playing catch-up with features that are primarily intended for psql sessions doesn't really fit well when Python's ssl has its own means for configuring policies.

#122

[jwp]

Plan for this will be to introduce the secure parameter in v1.4, and emit deprecation warnings in a subsequent bug fix.