It appears that not passing a connection will make it so that inspect
down the road fetches a connection from the pool:

`inspect.active()` delegate internally to `_request`:
https://github.com/celery/celery/blob/92514ac88afc4ccdff31f3a1018b04499607ca1e/celery/app/control.py#L136-L149

which delegates back to `control.broadcast`, passing the connection and
some other options:
https://github.com/celery/celery/blob/92514ac88afc4ccdff31f3a1018b04499607ca1e/celery/app/control.py#L105-L111

`broadcast` documents the `connection` option:
https://github.com/celery/celery/blob/92514ac88afc4ccdff31f3a1018b04499607ca1e/celery/app/control.py#L744-L756

    > connection (kombu.Connection): Custom broker connection to use,
    > if not set, a connection will be acquired from the pool.

Fetching the connection from the pool appears to not work well with
`max-tasks-per-child`, which makes it recycle the worker every time it
processes the amount of tasks configured. In other words, with
`max-tasks-per-child=10`, whenever a worker reaches 10 tasks processed,
a new worker will replace the old one:
https://docs.celeryq.dev/en/v5.4.0/userguide/workers.html#max-tasks-per-child-setting

The "replacing of workers" with the combination of fetching a new
connection from the pool results in time out errors and workers stop
processing any tasks:

    [2024-12-02 15:38:34,568: ERROR/MainProcess]
      Timed out waiting for UP message from <ForkProcess(ForkPoolWorker-4, started daemon)>
    [2024-12-02 15:38:34,571: ERROR/MainProcess]
      Process 'ForkPoolWorker-4' pid:20235 exited with 'signal 9 (SIGKILL)'

This error goes on an on, as the main process enters in a loop trying to
boot up a new worker and failing every time, potentially because of
having to wait for a connection from the pool, that's never made
available. I'm guessing that's exhausting the pool, possibly with
acquiring too many connections in between workers being replaced, and it
gets into a lock state that cannot recover and starts to time out.
(because the pool will lock while waiting for a connection to become
available, and it also seems to return write connections by default,
which we don't need.)

We already have a read-only connection available within our collector
that we can simply reuse, passing it down to the inspect object that can
be shared, so no need to mess with the pool and avoiding getting into
this lock state. This change should fix the time out issue above and
continue to process all tasks just fine.

Use acquired connection for inspecting active workers / tasks