* 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.
