Description:
------------
I enabled the PHP-FPM status page and configured a handler in Apache2:

```
<Location /status>
        SetHandler "proxy:unix:/run/php/php8.0-fpm.sock|fcgi://localhost/status"
</Location>
```

This is the result:

```
pool:                 www
process manager:      static
start time:           28/Jan/2021:15:53:44 +0100
start since:          1147547
accepted conn:        1054191
listen queue:         0
max listen queue:     0
listen queue len:     0
idle processes:       11
active processes:     1
total processes:      12
max active processes: 12
max children reached: 0
slow requests:        0
```

As can be seen, while all running processes have been used concurrently (this is the case after a few hours already, so not a very rare event), the listen queue stays at zero. Especially the `listen queue len` stays at zero, even that `listen.backlog = 1024` is applied in the pool configuration and as well system-wide a sufficient backlog is permitted:

```
net.core.somaxconn = 2048
net.ipv4.tcp_max_syn_backlog = 1024
```

This is on PHP8.0.2, but it was the same before on PHP8.0.1 and PHP7.4.

Steps to reproduce the behavior:

1. Install Debian Bullseye
2. Install Apache2 and PHP-FPM
3. Enable the PHP-FPM status page and the related handler in Apache2
4. Cause more concurrent requests than `pm.max_children`
5. Watch PHP-FPM status page to show `listen queue len` and `max listen queue` being zero.

Probably related bug report: https://bugs.php.net/bug.php?id=76323

Expected result:
----------------
I would expect that `listen queue len` matches `listen.backlog` and that I do see a non-zero value at `max listen queue`, when the process limit is hit regularly. But probably in this setup it is handled differently? At least connections are not dropped from what I can say, no related error messages appear in either PHP or Apache2 logs, so in fact requests are queried somewhere.

Actual result:
--------------
listen queue:         0
max listen queue:     0
listen queue len:     0