pgconn: support configuring the pgproto3 tracer before opening a connection

[achille-roussel]

The pgproto3 tracer was only configurable after establishing a connection, which means that there were no means to trace the initial messages exchanged during the connection handshake.

This PR adds two new fields to pgconn.Config: Tracer and TracerOptions, to support configuring the tracer earlier during the connection lifecycle, and have it trace the handshake messages.

I also added methods to TracerOptions to support parsing the tracer messages. My intent is to use those parsing functions to reconstruct structured data from those messages. I took this approach to avoid making any breaking changes on inconsistencies, since the io.Writer-based API was already supported.

Finally, I modified the internal tracer implementation a bit to minimize heap allocations, especially on paths that would allocate intermediary strings to format the tracer messages.

Let me know if you have any feedback.

[jackc]

What is the overall use case?

I anticipated tracing functionality is an occasional debugging tool and as a nice to have in common with the C library libpq. I did not anticipate it being performance sensitive or parsing the messages.

[achille-roussel]

I'm capturing those and recording them as structured logs. The performance impact is useful but not strictly necessary, from looking a the code and git history, I noticed there was some work already done to ensure the cost would remain low.

Let me know if I overlooked a feature that would allow me to capture the initial connection messages, I'm not particularly attached to this model, just looking for a way to capture those.

[jackc]

I'm not against these changes. But I want to make sure there is not a better way. This system is constrained by the desire to be compatible as much as possible with libpq PQtrace. Not all message data is exposed.

If you want complete control without any code changes, then is possible to use pgconn.Config.AfterNetConnect to observe the traffic over the wire, parse the messages, and do what you see fit with them (even modify messages). This does entail a bit of overhead as traffic is decoded twice (and encoded twice if you modify a message), but it allows you to do anything.