test(profiling): unflake test_gunicorn (#19694)

## Description

This PR is an attempt to unflake `test_gunicorn`. 

`test_gunicorn` previously asserted a 5s `urlopen` timeout against a request that computes a recursive `fib(35)` inline in the handler. That work takes about 3s on 3.10 (which is the one that keeps flaking) and it seems like in practice we can accidentally timeout due to this. 

In the last failure on `main` ([job 1949343458](https://gitlab.ddbuild.io/DataDog/apm-reliability/dd-trace-py/-/jobs/1949343458)) the worker was healthy and did serve the request -- it logged `"GET / HTTP/1.1" 200` 5.08s after the client sent it, but after  `urllib` gave up. The auto-retry in the same job passed with the identical request taking 4.37s, so pass/fail hinged on ~600ms of runner jitter. 



Co-authored-by: thomas.kowalski <thomas.kowalski@datadoghq.com>

Author: KowalskiThomas

tests/profiling/test_gunicorn.py

@@ -107,7 +107,10 @@ def _test_gunicorn(
 
     debug_print("Making request to gunicorn server")
     try:
-        with urllib.request.urlopen("http://127.0.0.1:7644", timeout=5) as f:
+        # The handler computes fib(35), which takes over 3s on py3.10 and has been measured at
+        # 5s on a loaded CI runner. This timeout only guards against a hung worker, so it needs
+        # margin over that rather than to be tight.
+        with urllib.request.urlopen("http://127.0.0.1:7644", timeout=20) as f:
             status_code = f.getcode()
             assert status_code == 200, status_code
             response = f.read().decode()