pgconn: add configurable max message body length

[carter-ya]

Summary

• Add pgconn.Config.MaxBodyLen and apply it to pgproto3.Frontend during ConnectConfig and Construct.
• Add regression coverage for configured body length limits.

Rationale

pgproto3.Frontend already supports SetMaxBodyLen, but pgconn users currently need to reach through to the protocol frontend to configure it. Exposing the setting on pgconn.Config makes it possible to reject unreasonable message bodies before chunkReader allocates the buffer.

The default remains 0, so no maximum is enforced unless callers opt in. This preserves the existing behavior while allowing applications to configure a defensive limit.

Testing

• go test ./pgproto3 ./pgconn -run 'TestFrontendReceiveExceededMaxBodyLen|TestBackendReceiveExceededMaxBodyLen|TestConnectConfigMaxBodyLen|TestConfigCopyReturnsEqualConfig'

[jackc]

Is MaxBodyLen the right name for this at the pgconn.Config layer? It has a clear meaning at the pgproto3.Frontend layer. But at the connection / config layer I'm not sure I would immediately understand what it meant. 🤷

[carter-ya]

Is MaxBodyLen the right name for this at the pgconn.Config layer? It has a clear meaning at the pgproto3.Frontend layer. But at the connection / config layer I'm not sure I would immediately understand what it meant. 🤷

Good point. MaxBodyLen mirrors the pgproto3.Frontend API, but I agree it may be too protocol-internal for pgconn.Config.

Would you prefer one of these directions?

1. Keep it as a top-level pgconn.Config field, but use a more explicit name, e.g. MaxProtocolMessageBodyLen.
2. Add a small protocol namespace, e.g. Config.Protocol.MaxMessageBodyLen, so future protocol-level frontend options have a clearer home.

My current leaning is option 1 as the smallest API change, but option 2 may be cleaner if you expect more protocol-level knobs to be exposed later.

[jackc]

One additional bit of information: this already can be configured on connection with Config.BuildFrontend. This feature doesn't enable new functionality, it makes it a bit easier to use. Depending on how frequently this is used, it may or may not be necessary to add this helper. That said, I'm willing to accept it.

I would go for the top-level pgconn.Config field. That matches what we already have with MinProtocolVersion and MaxProtocolVersion.