Log thread backtraces and GC stats for app debugging

[wjordan]

Description

Three changes in this PR:

1. Update our Puma fork to the latest upstream version (4.3.1), with a slightly different approach to request-balancing and some extra debugging hooks for thread backtrace and gc stats;
2. Add a plugin (LogAppStats) to log app stats every second across all worker processes for debugging purposes, that can be dynamically switched on/off by a flag.
3. Add before_fork code to (re-)launch DCDO and Gatekeeper update-threads in the parent. This fixes a bug where DCDO/Gatekeeper entries were not getting updated in the daemonized parent process in cluster (workers > 0) + daemon (-d) mode.

Testing Story

Manual testing on an adhoc to confirm the logging and dynamic configuration work as expected. No automated testing at this point since the instrumentation was developed quickly, and intended to be enabled only for temporary/debugging purposes.

[uponthesun]

Code changes look fine to me, but is it necessary to combine the instrumentation changes with pulling in the upstream Puma updates? The latter carries extra potential for risk / unexpected changes that might confound our investigation, doesn't it?

If it is reasonable to decouple the two my preference would be to deploy the instrumentation changes first and record the results before deploying the Puma updates.

[wjordan]

Good point @uponthesun - I've separated out the version update from the instrumentation and updated the PR- here is the updated diff.

[uponthesun]

Thanks for doing this! Cool to see how this works.