Title: Allow Postgres proxy to upgrade unencrypted downstream connection into encrypted upstream connection

Description:

The PostgreSQL filter supports TLS termination: #14634 In this mode, it accepts an encrypted client connection (downstream), strips TLS, and creates an outgoing unencrypted connection to the SQL DB (upstream).

Conversely, it should support the opposite where Envoy accepts unencrypted (sslmode=disable) Postgres connections, adds StartTLS on top, and dials securely to the upstream.

This is particularly useful for Google Cloud SQL which enforces the use of client certificates.
Unfortunately a few Postgres clients (such as Rust's tokio-postgres) don't support client certs.
So a service proxy is required to establish a secure connection.
(Google Cloud SQL specifically provides the cloud_sql_proxy tool for this reason but obviously Envoy is a preferred choice given its maturity)

Defining a starttls transport socket on the cluster config in Envoy v1.21 results in surprising behavior.
When making an insecure connection to Envoy, the Postgres filter will just pass through the connection attempt to the upstream without attempting to upgrade the socket into TLS mode.

Proposed fix:

• Introduce a new upstream_sslmode string that mirrors the available PostgreSQL sslmode settings.
• When upstream_sslmode is defined, send that to the upstream instead of the sslmode specified by the client.
• When upstream_sslmode is prefer, require, verify-ca, or verify-full and the downstream connection is unencrypted, initiate an upstream StartTLS upgrade.

Useful links:

• PostgreSQL SSL: https://www.postgresql.org/docs/9.1/libpq-ssl.html
• Google Cloud SQL SSL settings: https://cloud.google.com/sql/docs/postgres/configure-ssl-instance#client-certs
• Google cloud_sql_proxy: https://github.com/GoogleCloudPlatform/cloudsql-proxy