azcosmos: intermittent empty 500 responses when reusing idle HTTP connections in Kubernetes

### Bug Report <!-- Thank you for opening a bug report. For faster processing, please include: --> - import path of package in question: ``github.com/Azure/azure-sdk-for-go/sdk/data/azcosmos`` - SDK versions - github.com/Azure/azure-sdk-for-go/sdk/azcore v1.21.0 - github.com/Azure/azure-sdk-for-go/sdk/azidentity v1.13.1 - github.com/Azure/azure-sdk-for-go/sdk/data/azcosmos v1.4.2 - github.com/Azure/azure-sdk-for-go/sdk/tracing/azotel v0.4.0 - output of `go version`: 1.25.0 <!-- and please describe: --> - #### What happened? Experienced an issue 3 times so far where a Kubernetes pod suddenly starts receiving 500 errors from various Cosmos containers in Azure: ``` GET xxxxx -------------------------------------------------------------------------------- RESPONSE 500: 500 Internal Server Error ERROR CODE: 500 Internal Server Error -------------------------------------------------------------------------------- Response contained no body -------------------------------------------------------------------------------- ``` These errors are not specific to a single container, and restarting the pod only temporarily resolves the issue. We reuse idle connections and it appears that this may relate to how the SDK interacts with the Go http client. Since it returns an empty response, these responses do not record the activity ID. - #### What did you expect or want to happen? We expected to either: - Not receive 500 errors from the SDK layer when the Cosmos DB backend is not returning 500s, and/or - Receive detailed error responses, ideally with information like the activity ID (x-ms-activity-id header). - #### How can we reproduce it? Reusing the idle connections from kubernetes pods using the above SDK versions and Cosmos. Over a period, the pod starts reporting 500s with empty responses for all the requests going through that pod. Intermittent issue, but seen 3 times in Kubernetes pod using the above SDK versions and Cosmos. - #### Additional information - We have already followed up with the Azure support, who confirmed these 500s do not come from their backend service. - All observed 500s with empty response bodies occur when reusing idle HTTP connections. <!-- Thanks! -->