pgbouncer prestop command is not graceful enough

### Under which category would you file this issue? Helm chart ### Apache Airflow version 2.11.0(airflow version is not applicable to this issue) ### What happened and how to reproduce it? To reproduce: - perform a rolling restart of the pgbouncer deployment(with multiple replicas) in an airflow cluster and kubernetes cluster under heavy load - observe scheduler, dag-processor, and worker pods - some pods will see restarts with a SQL connection error like "No route to host" or "Connection refused" ### What you think should happen instead? The prestop command used for pgbouncer in the helm chart(shown below) is problematic: ``` containerLifecycleHooks: preStop: exec: # Allow existing queries clients to complete within 120 seconds command: ["/bin/sh", "-c", "killall -INT pgbouncer && sleep 120"] ``` Although `killall -INT pgbouncer` does in fact trigger a safe shutdown as expected, it exits as soon as in-flight queries drain. Once this occurs, the liveness probe terminates the pod regardless of whether the `sleep 120` has finished or not. In the event of an idle pgbouncer pod or one with no long-running queries, this happens in ~1 second or less. The container therefore stops accepting connections before the EndpointSlice/kube-proxy updates triggered by the pod entering Terminating have propagated, so new connections routed to the still-registered (but dead) pod fail with connection errors. I've fixed this by putting a short sleep command in front of `killall -INT pgbouncer` like so: ``` containerLifecycleHooks: preStop: exec: # Allow existing queries clients to complete within 120 seconds command: ["/bin/sh", "-c", "sleep 10 && killall -INT pgbouncer && sleep 20"] ``` This allows the pod to transition to a `terminating` state while the pgbouncer container continues to run, which grants kubernetes more time to remove the target from the service endpoint and update the loadbalancer and kube-proxy rules. Now, …