Starting your server with BUNDLE_GEMFILE=Gemfile.rails6 would delete this
environment variable on app restart when using `--prune-bundler`, when
all you really want is to restore the variable to what it was before
Bundler was activated.

I mimicked the existing code that preserves GEM_HOME.

Co-authored-by: James Miller <bensie@gmail.com>

Test that the environment is not lost when doing a restart by using the
PATH env var as a canary. While we actually care about the
BUNDLER_GEMFILE env var, that one is harder to set up in testing since
it requires a full copy of Puma's Gemfile.

This change also has the benefit of not only protecting the
BUNDLE_GEMFILE var, but also the other variables that Bundler knows
about.

Starting your server with BUNDLE_GEMFILE=Gemfile.rails6 would delete this
environment variable on app restart when using --prune-bundler, when all
you really want is to restore the variable to what it was before Bundler
was activated.

Writing a test for this proved to be difficult because the bug only seems
to manifest itself when running the server under the following conditions:

- Using `bundle exec` to run the puma command
- Using a non-zero number of workers, e.g. `-w 2`
- Setting `BUNDLE_GEMFILE` to something other than "Gemfile"

On my machine, the USR2 signal was being sent to Bash, but not to to
puma itself. I don't understand why this only affected Ruby 2.2 though!

This test was failing on Travis when run in parallel with other tests in
the TestIntegrationCluster test. Removing the line "parallelize_me!"
from the top of the file worked, but I chose to move the test into its own
file to keep the existing tests running in parallel.

...and go back to using Bundler.with_clean_env.