Print warning when running one-worker cluster

[CGA1123]

Running Puma in cluster-mode is likely a misconfiguration in most
scenarios.

Cluster mode has some overhead of running an addtional 'control' process
in order to manage the cluster. If only running a single worker it is
likely not worth paying that overhead vs running in single mode with
additional threads instead.

There are some scenarios where running cluster mode with a single worker
may still be warranted and valid under certain deployment scenarios, see
the linked issue for details.

From experience at work, we were able to migrate our Rails applications
from single worker cluster to single-mode and saw a reduction of RAM
usage of around ~15%.

Closes #2534

Your checklist for this pull request

• I have reviewed the guidelines for contributing to this repository.
• I have added an entry to History.md if this PR fixes a bug or adds a feature. If it doesn't need an entry to HISTORY.md, I have added [changelog skip] or [ci skip] to the pull request title.
• I have added (or updated) appropriate tests if this PR fixes a bug or adds a feature.
• My pull request is 100 lines added/removed or less so that it can be easily reviewed.
• If this PR doesn't need tests (docs change), I added [ci skip] to the title of the PR.
• If this closes any issues, I have added "Closes #issue" to the PR description or my commit messages.
• I have updated the documentation accordingly.
• All new and existing tests passed, including Rubocop.

[dentarg]

I think it would be good to be able to silence the warning, as outlined in #2534, there might be users who really want to run Puma this way.

[dentarg]

A test would also be good, so future refactoring can be done with confidence. Looks like test_run_hooks_and_exception could provide some inspiration for that.

[CGA1123]

@dentarg Thanks for taking a look!

What would be the preferred way to suppress this warning? Via an environment variable? A new configuration option?

[dentarg]

I would go for environment variable

[nateberkopec]

Env variable seems like the wrong choice @dentarg - wouldnt you want this warning to be supressed "for all time"? Env variables mean that other devs in dev environments, for example, would have to also have the env variable set.

[dentarg]

@nateberkopec you're right, that makes sense. I was thinking of other types of software where ENVs is often used to hide warnings.

I guess an ENV is good if you're in a situation where you can't change the config for some reason but you have control over the environment. (Might not be a common thing with this case)

[CGA1123]

In that case then should this be implemented as a new method in Puma::DSL or as a new keyword argument to Puma::DSL#workers? or something else?

One potential issue with adding it as a new keyword argument to #workers is that many people may be relying on the WEB_CONCURRENCY environment variable to manage worker counts.
So it may be more appropriate to add it as a new DSL method? silence_single_worker_warning or something like that?

[dentarg]

So it may be more appropriate to add it as a new DSL method? silence_single_worker_warning or something like that?

Sounds good to me 👍 The warning could inform about this setting

[CGA1123]

I'm not sure that the failing test is related to these changes, seems like a flake!