Add a dedicated cancel_wait_timeout

[JelteF]

Cancellations and regular queries are quite different. So it makes sense
to have different (default) timeouts for cancellation requests than for
queries. While I already think the default query_wait_timeout of 120
seconds we have is excessively long, it doesn't make sense at all to
have such a long timeout by default for cancellation requests that are
not sent. So this introduced a new cancel_wait_timeout which is set to
10 seconds by default. If the cancellation request cannot be forwarded
within that time it's probably better to drop it.

One reason why it's important to relatively quickly close cancellation
requests when they are not being handled is because libpq only allows
the client to send a cancel in a blocking way. So there's no possibility
to bail out after a certain amount of seconds on the client side, if
PgBouncer keeps the connection to the client open. Both me and Marco
noticed this when testing my PgBouncer peering PR (#666), when an entry
in the [peers] list pointed to an unreachable host. That meant that
pgbouncer would keep the cancel connection open, and even though the
query had finished the psql would not display the result because it
was stuck waiting for a result to the cancel request.

To avoid race conditions of cancellations that already forwarded, but
not yet answered cancellation requests are not timed out. See #717 for
details on such race conditions.

[petere]

I wonder if the "Dangerous" is really appropriate here, or was it just copied from the query_ settings?

[JelteF]

Disabling it is definitely dangerous, but yeah it was mostly copied.