**Describe the bug**:
I was faced with a very strange and weird issue. When ELK server fails and responds with 500 error, a current HTTP request fails too and my server responds with 500 status and plain text from ELK response. And this error doesn't pass through any middleware, I have a couple of them, one for sentry integration and another for error message transforming, and none of them was triggered.

This is a full logs from my app:

```python
Failed to submit message: 'HTTP 500: \r\n500 Internal Server Error\r\n\r\n

500 Internal Server Error

\r\n

---

nginx/1.20.1\r\n\r\n\r\n'
Traceback (most recent call last):
File "/usr/local/lib/python3.11/site-packages/elasticapm/transport/base.py", line 279, in _flush
self.send(data, forced_flush=forced_flush)
File "/usr/local/lib/python3.11/site-packages/elasticapm/transport/http.py", line 114, in send
raise TransportException(message, data, print_trace=print_trace)
elasticapm.transport.exceptions.TransportException: HTTP 500:
500 Internal Server Error

500 Internal Server Error

---

nginx/1.20.1


```

**To Reproduce**

Unfortunately, I can't reproduce it in my dev configuration. It happens only in production environment.
But I guess it happens like that:
1. A python server receives HTTP request from a user for example on root path "/"
2. Around the same time the elk-apm lib tries to send some data to elk server
3. Server responds with 500 error
4. ???
5. Somehow this error passed through to end user, and the user sees 500 error with plain text from the original exception

**Environment (please complete the following information)**
- OS: Debian GNU/Linux 11 (bullseye)
- Python version: 3.11.3
- Framework and version: Fastapi 0.92.0
- APM Server version:
- Agent version: 6.15.1

**Additional context**

- Agent config options

Click to expand

```
APM_ENABLED: 'True'
APM_DEBUG: 'False'
APM_SERVICE_NAME: "project"
APM_ENVIRONMENT: "production"
APM_CLOUD_PROVIDER: "aws"
APM_TRANSACTION_IGNORE_URLS: "[]"
APM_SERVER_URL: "https://some.host"
APM_SERVER_TIMEOUT: "10s"
APM_SAMPLE_RATE: "1.0"
APM_LOG_LEVEL: "info"
APM_TRANSPORT_CLASS: "elasticapm.transport.http.Transport"
```

- `requirements.txt`:

Click to expand

```
alembic==1.9.4
anyio==3.6.2
asyncpg==0.27.0
authlib==1.2.0
certifi==2022.12.7
cffi==1.15.1
click==8.1.3
cryptography==39.0.2
dnspython==2.3.0
elastic-apm==6.15.1
email-validator==1.3.1
fastapi==0.92.0
greenlet==2.0.2
h11==0.14.0
httpcore==0.16.3
httpx==0.23.3
idna==3.4
jinja2==3.1.2
mako==1.2.4
markupsafe==2.1.2
prometheus-client==0.16.0
prometheus-fastapi-instrumentator==5.10.0
psycopg==3.1.8
pycparser==2.21
pydantic[email]==1.10.5
pyjwt==2.6.0
pyotp==2.8.0
python-multipart==0.0.6
rfc3986[idna2008]==1.5.0
sentry-sdk==1.16.0
sniffio==1.3.0
sqlalchemy==2.0.4
starlette==0.25.0
typing-extensions==4.5.0
urllib3==1.26.14
uvicorn==0.20.0
wrapt==1.15.0
```

Beginne mit elasticapm/transport/base.py bei _flush und elasticapm/transport/http.py bei send und verfolge anschließend, wie eine fehlgeschlagene APM-Übermittlung einen FastAPI-Request erreichen könnte. Reproduziere das Timing in der Produktion mit einem APM-Server, der HTTP 500 zurückgibt, und prüfe, ob die Exception die gemeldete Middleware umgeht. Als abgeschlossen gilt die Aufgabe, wenn der Fehlerpfad isoliert und durch einen Regressionstest abgedeckt ist.

Vom Indexierungsmodell aus dem Issue-Text verfasst.