* Revert api change from #2086 introduce Puma.stats_hash api
The change in #2086 is not backwards compatible with existing gems that parse the output of Puma.stats such as barnes.
Releasing a version of puma with this change would break anyone using the Barnes app and only in production. I'm proposing to keep the existing interface and instead add a new API. This buys us all the features of #2086 without causing any production facing downtime by customers due to API incompatibilities.
Unfortunately it requires that we serialize and the de-serialize the values. One prior benefit of returning json in a string was that it allowed an end user to de-serialize using a faster json algorithm such as `oj` via the "multi json" gem. But the performance penalty will be better than a stability break.
* Add frozen string literal everywhere it wasnt already
* Enforce stopgap for tests
* Small amount of integration test cleanup
* Parallelize and freeze Test_app_status
* Big cleanup for test_binder
* Whitespace fix
Right now to get stats for a puma process the only way is to go through the control server. The puma-stats-logger does this by reading in a state file then querying the control server manually.
7ad7798e9d/lib/puma_stats_logger/middleware.rb (L28)
Instead, I’m proposing adding a top level `Puma.stats` method that will allow anyone inside of the same process to get access to the stats.
This could be instrumented by a gem to theoretically export these stats to say a Heroku dashboard where we could list out backlog or thread count.
The format of stats is a hash, and will change depending on if the server is in “single” or “clustered” mode.
Clustered:
```
{ "workers": 2, "phase": 0, "booted_workers": 2, "old_workers": 0, "worker_status": [{ "pid": 19832, "index": 0, "phase": 0, "booted": true, "last_checkin": "2018-03-12T16:03:12Z", "last_status": { "backlog":0, "running":5 } },{ "pid": 19833, "index": 1, "phase": 0, "booted": true, "last_checkin": "2018-03-12T16:03:12Z", "last_status": { "backlog":0, "running":5 } }] }
```
Single:
```
{ "backlog": 0, "running": 2 }
```
Alternatively if we could somehow enable another process to get these stats from Puma via pumactl by default without requiring any additional in app config, that would also work.
This is a WIP. This was the minimum I could do to get all tests to pass without changing any tests. Eventually I think we want all high level process controls to come from launcher, I also think we want another separate object that gets passed to Runner/Single/Cluster that will maintain a relationship with the Launcher. We could use this as the object that also gets exposed to the app like the Embeddable class we talked about earlier.
Moving forwards i'm planning to port out the CLI tests to only test that they are parsing the correct config and launching servers. I'll port all low level unit tests over to the launcher. Making this change we could either keep all the public methods in CLI that delegate to `@launcher`, I'm guessing not many people are using the internals of CLI and we can take them out. It's your call though.
Wanted to kick this over the fence and see if you had any strong reactions or feelings about this approach.
