Kubernetes provider `kubernetes_executor.enable_tcp_keepalive` does not actually enable TCP keepalives

### Under which category would you file this issue? Providers ### Apache Airflow version 3.2.1 ### What happened and how to reproduce it? **Issue Description** Noticed while debugging an issue with out schedulers crash looping because of K8s liveness probes failing that connections opened to the Kubernetes API server were getting stuck in a `CLOSE_WAIT` state. Meaning next time the connection was pulled from the connection pool it would be unable to make API calls successfully. These connections were never removed from the connection pool and remained in the pool in that state. This ended up being a red herring for what was causing the crash-looping though. There was high DB load on our metadata DB and this presumably caused scheduler loop to slow down which in turn caused delay between k8s API calls giving an opportunity for the connections in the k8s API connection pool to be dropped by the NLB in front of the k8s API server. Once we fixed the issue with the metadata DB the issue with the k8s api connection pool and `CLOSE_WAIT` state connections resolved itself. But this issue with keep alives could affect anyone that has a load balancer in front of the K8s API server as is common in cloud environments like AWS/GCP/Azure where a connection timeout is configured. Digging into the code for the k8s provider it appears the mechanism used to enable TCP keepalives no longer works with urllib3 v2.x. It relies on new HTTPConnection/HTTPSConnection using HTTPConnection.default_socket_options as a default when no socket_option argument is provided. But in urllib3 v2.x the HTTPSConnection/HTTPConnection __init__ function sets socket_options as a default argument value when not provided meaning it gets evaluated at module import time. Since `_enable_tcp_keepalive` overwrites `HTTPConnection.default_socket_options` the changes are never used when creating new `HTTPConnection` objects. I also wonder if instead of trying to patch `default_socket_options` would it make more sens…