Do not wait server_login_retry for next connect if cancellation succeeds
If postgres restarts while there are N cancellations in the queue,
pgbouncer is currently unavailable for at least N*server_login_retry
because it uses every new connection for one queued cancellation and
then waits server_login_retry before opening a new connection because
the last_connect_failed flag is still set to 1. This can lead to
prolonged downtime.
This changes fixes the issue by introducing a last_login_failed flag.
The last_connect_failed is now reset when a cancellation succeeds, such
that launch_new_connection no longer waits if pgbouncer manages to
connect, but has queued cancellations. The last_login_failed flag has
the same semantics as the last_connect_failed flag had previously, such
that check_fast_fail still rejects connections when there are no servers
available and the last login failed.