Only use positive numbers in the PID part of the cancel key

[JelteF]

We were using the full 64 bits of the BackendKeyData message as random
bytes. This turned out to be arguably incorrect, because the first 32
bits are used by PostgreSQL as a Process ID (and this is part of the
protocol documentation too). Actual PIDs are always positive, but
we also put a random bit in the sign bit so were setting it to negative
numbers half of the time. For most cases this does not matter, but it
turned out that pg_basebackup relied on the PID part to actually be
positive.

While pg_basebackup is now fixed to support negative Process IDs, it
still seems good to adhere to this implicit requirement on positive
numbers in case other clients also depend on it.

Since this change requires changing the bytes of the cancel key in which
we encode the peer_id, this change breaks cancelations in peered
clusters of different PgBouncer versions. This seems like a minor
enough problem that we should not care about this. In practice this
should only happen during a rolling upgrade, which we currently don't
support well anyway (see #902 for improvements on that). And even if we
did, breaking cancellations for a few minutes in this transitional stage
doesn't seem like a huge deal.

[petere]

While pg_basebackup is now fixed to support negative Process IDs, it still seems good to adhere to this implicit requirement on positive numbers in case other clients also depend on it.

That makes sense.

Since this change requires changing the bytes of the cancel key in which we encode the peer_id, this change breaks cancelations in peered clusters of different PgBouncer versions. This seems like a minor enough problem that we should not care about this. In practice this should only happen during a rolling upgrade, which we currently don't support well anyway (see #902 for improvements on that). And even if we did, breaking cancellations for a few minutes in this transitional stage doesn't seem like a huge deal.

I don't think I follow this. While temporary breakage during rolling upgrades might be a minor problem, what about different pgbouncer versions on different hosts that are peered together? We don't want to force that all of those are upgraded together.

Maybe a compatibility break is necessary, but then we should just say so.

What would happen if we left the peer ID as is (in the first bytes)?

[JelteF]

Maybe a compatibility break is necessary, but then we should just say so.

Fair enough. I'll update the docs in the PR and note that cross version peering is not supported across this version change. (and also include it in the changelog)

What would happen if we left the peer ID as is (in the first bytes)?

Then we'd cut the usable peer id space in half, because the sign bit always needs to be 0. The maximum value of peer_id (16383) is also documented, so changing that would also be a breaking change. Since we're breaking compatibility either way, I'd rather do it in the way that the PR is doing now so we can keep the same amount of peer_ids.

[JelteF]

I updated the docs to include the cross-version breakage.