Allow using built-in process manager with one worker

[eltoder]

Uvicorn has a built-in process manager, so I can run it with, for example, --workers 4 to get 4 worker processes. Uvicorn will run 4 child processes listening on the same port, and will automatically restart processes that die or get stuck. However, if I use --workers 1, Uvicorn will not use its process manager and will instead run the ASGI application directly in the main process.

I have a use case where I only need one worker process, but I need to monitor and restart it on failures. I can use an external process manager like gunicorn or supervisor, but it seems unfortunate to introduce another dependency when everything I need is already supported by Uvicorn itself. The built-in process manager can already run with just one worker by starting with --workers 2 and then sending SIGTTOU. Alternatively, I can copy code form main.py and use Multiprocess directly. However, both of these options seem hacky.

I propose that running Uvicorn with --workers 1 runs the application in a subprocess using Multiprocess process manager. This is both a useful feature and seems more intuitive. Happy to open a PR.

This will also address the issue discussed here: #2390

[tayfuryldz]

Current main confirms the behavior: the process-manager branch is explicitly gated by config.workers > 1, and Config.should_reload similarly treats only reload or more than one worker as requiring the subprocess setup.

I would avoid changing the meaning of --workers 1, though. Today it is also the default (self.workers = workers or 1), so making “1” enter Multiprocess would move every ordinary Uvicorn invocation into a parent/child topology. That changes signal handling, PIDs, debugger behavior, startup failure reporting, and container process semantics for users who never requested supervision.

The underlying feature makes sense, but it needs a separate opt-in from worker count. For example, a supervisor/process-manager flag could mean “run workers under Uvicorn's Multiprocess supervisor” while --workers continues to mean only how many worker processes are desired. Then --workers 1 --<supervisor-flag> provides the requested restart/health-check behavior without changing the default execution model.

That also avoids overloading workers with two independent questions: cardinality and whether there should be a supervising parent process.

Tests should cover both contracts: default / --workers 1 remains the direct server path for compatibility, while the explicit supervisor mode with one worker creates a child and restarts it using the same health-check path as the existing multi-worker manager.