Support replication connections through PgBouncer

[JelteF]

In session pooling mode PgBouncer is pretty much a transparent proxy,
i.e. the client does normally not even need to know that PgBouncer is in
the middle. This allows things like load balancing and failovers without
the client needing to know about this at all. But as soon as replication
connections are needed, this was not possible anymore, because PgBouncer
would reject those instead of proxying them to the right server.

This PR fixes that by also proxying replication connections. They are
handled pretty differently from normal connections though. A client and
server replication connection will form a strong pair, as soon as one is
closed the other is closed too. So, there's no caching of the server
replication connections, like is done for regular connections. Reusing
replication connections comes with a ton of gotchas. Postgres will
throw errors in many cases when trying to do so. So simply not
doing it seems like a good tradeoff for ease of implementation.
Especially because replication connections are pretty much always
very long lived. So re-using them gains pretty much no performance
benefits.

Fixes #382

Depends on #945

[Melkij]

So re-using them gains pretty much no performance benefits.

Moreover, replication connections cannot be reliably reused at all. Attempting to do so will lead to various mysteries like

elog(ERROR, "no record found"); /* shouldn't happen */

in wal sender code. Wal sender implicitly assumes that it works with one wal receiver.
(Based on my experience with a single cloud service where admins tried to use connection pooling for replication too)

[JelteF]

Moreover, replication connections cannot be reliably reused at all.

Thanks. I updated the wording in the PR to include that.

[eulerto]

Isn't the cancel key change a requirement to this feature? I suggest you to create a separate commit for it.

[eulerto]

Isn't the cancel key change a requirement to this feature? I suggest you to create a separate commit for it.

Ops... I realized that you did it. Another suggestion is to explain in the commit message that it is a requirement for this feature.

[JelteF]

Ops... I realized that you did it. Another suggestion is to explain in the commit message that it is a requirement for this feature.

I added a commit message and moved it before the actual replication change, but while doing that I realized I thought the change was special enough to warrant its own PR, so I made a new one: #945

All review items are resolved now