Add support for protocol 3.2

[dbussink]

This adds support for the 3.2 protocol version, introduced with PostgreSQL 18.

It follows postgres in the sense that the default is still 3.0, but this allows for allocations to allow the 3.2 version of the protocol with longer secret key data.

This is to both improve security and to provide room for additional metadata for middleware.

See also jackc/pgx#2498 for a similar change I submitted there.

[arp242]

This is to both improve security and to provide room for additional metadata for middleware.

As I understand it, protocol 3.2 just adds the longer key length for security? I'm not sure if I follow what you mean with "additional metadata for middleware"?

[dbussink]

As I understand it, protocol 3.2 just adds the longer key length for security? I'm not sure if I follow what you mean with "additional metadata for middleware"?

Because it is not only for security. As called out in the documentation:

https://www.postgresql.org/docs/current/protocol-message-formats.html#PROTOCOL-MESSAGE-FORMATS-BACKENDKEYDATA

Byten
The secret key of this backend. This field extends to the end of the message, indicated by the length field.

The minimum and maximum key length are 4 and 256 bytes, respectively. The PostgreSQL server
only sends keys up to 32 bytes, but the larger maximum size allows for future server versions, as
 well as connection poolers and other middleware, to use longer keys. One possible use case is
augmenting the server's key with extra information. Middleware is therefore also encouraged to
not use up all of the bytes, in case multiple middleware applications are layered on top of each
other, each of which may wrap the key with extra data.

Before protocol version 3.2, the secret key was always 4 bytes long.

So next to the enhanced security, it is also an explicit use case to be able to use this for middleware. This is useful if there's a system with multiple proxies sitting in front of various postgres instances so that proxies can for example route the request then to right proxy if a different proxy received the Cancel request.