Support PostgreSQL protocol and protocol extension negotiation

[hlinnaka]

The PostgreSQL frontend-backend protocol supports protocol negotiation, so that if the client supports a higher version of the protocol than the server, they can agree to use the lowest common denominator. In practice, that never happens because there haven't been any new protocol versions since that mechanism was introduced. The protocol version is always 3.0. The same mechanism can also be used to negotiate the use of optional protocol extensions. That is also not used in practice because no optional protocol extensions have been introduced.

There were some patches in the v17 release cycle to introduce protocol changes that would've used that mechanism, but they were not committed. For future-proofing, it would be nice to support the protocol negotiation in the proxy.

See NegotiateProtocolVersion at https://www.postgresql.org/docs/devel/protocol-flow.html.

[conradludgate]

Problem:

1. client <-> proxy - negotiates protocol version 3.1
2. proxy <-> compute - negotiates protocol version 3.0
3. client -> proxy -> compute - sends packet only on version 3.1

Needs to figure out how to resolve this early.

1. Perhaps we just limit proxy to min version supported by all neon compute versions
2. Alternatively deploy multiple proxies for different postgres (protocol) versions.

[conradludgate]

Alternative work around:

1. Control plane should know the compute version per endpoint
2. Proxy can cache this information
3. Protocol version is dispatched after TLS handshake, meaning we should have the endpoint ID in SNI.
4. If the endpoint name is unknown, and the protocol version is not 3.0, send back NegotiateProtocolVersion 3.0.
5. If the endpoint name is known, but the compute version is uncached, and the protocol version is not 3.0, send back NegotiateProtocolVersion 3.0.
6. If the endpoint name is known and the compute version is cached, negotiate based on the known supported protocol version of that compute version.

[conradludgate]

This would probably be less useful though. If a customer wants to make use of a new protocol feature, this would be inconsistent behaviour. I think I would prefer having different hostname/nlb/proxy per protocol version.

[conradludgate]

I went for the approach that downgrades the protocol for now. We can reconsider once there are protocol extensions that we might need to support. Either by implementing the translation in proxy, or by launching separate proxies.