feat: implement cancel request on postgres protocol

[sunng87]

I hereby agree to the terms of the GreptimeDB CLA.

Refer to a related PR or issue link (optional)

• Process management #5866

What's changed and what's your intention?

This patch implements cancel request on postgres protocol so the server can respond ctrl+c in psql.

PR Checklist

Please convert it to a draft if some of the following conditions are not met.

• I have written the necessary rustdoc comments.
• I have added the necessary unit tests and integration tests.
• This PR requires documentation updates.
• API changes are backward compatible.
• Schema or data changes are backward compatible.

[sunng87]

I will have to hold this implementation until postgres protocol 3.2 postgres/postgres@a460251 which makes the cancel key a little bit longer so we can carry enough information to identify the connection.

[sunng87]

Let me share more details about the status of this pull request.

First you may want to learn more about how cancel works in postgres https://www.postgresql.org/docs/18/protocol-flow.html#PROTOCOL-FLOW-CANCELING-REQUESTS

I just implemented postgres protocol 3.2 cancel request in this PR. This feature is expected to land on postgres in 18beta2. The client support may vary due to the variety of ecosystem.

In the current implementation, we use extra bytes to carry additional information required to kill a request in a multi-tenant, distributed database. The bytes includes:

• an int32 number: for verification of cancel request
• the original server addr: the server's intranet address
• the catalog name: which catalog name the query is running on

The whole idea is to be able to identify the connection in a distributed environment, where multiple frontends running postgres protocol. The cancel request may arrive at any random instance, and we will use RPC between frontends to send the cancel request.

There are more tasks:

• Is server id a better choice than server addr? Leaking server address may not be a good idea.
• We need to verify the secret key (int32 number) before cancelling the query. This key is stored in Session of the query.
• Do we need a checksum to make sure the cancel request is not fake?

[sunng87]

I'm considering removing catalog from rpc calls of east-west frontend communication, as well as secret key, because the process id is already a unique number.

We may also validation cancel request are sent from same IP as original connection.