Deployment is really managing pods in terms of readiness to serve. As soon as a pod is terminating, it is considered “done” from the Deployment’s POV and a new one is brought up.
AFAIK there is no way to ask for complete removal before replacement. It does not sound completely unreasonable but it doesn’t exist.
If you have such a finite pool, you need to handle retries internally, which you probably do anyway. Realistically, your outbound connections being limited effectively ARE state – just like a volume which cannot be double-mounted, you have to “hand off” these connection “slots”. You can either do that through some external mechanism (e.g. N leases) or simply try and retry.
If you don’t want to proceed in your rolling update until the connection is established, you might use a startupProbe which only becomes true once the connection is established, but be careful. Having a readiness probe which depends on an external service can lead to flapping of your service and overall worse experience.