Print test-scanning details if verbose flag is provided
git ignore command-line flags file
Sources bash_profile to fix 'install then run' bug

Also removes code that requires ~/FrameworkBenchmarks download directory (see #578)

This 'bug' happens if some tries to install and then immediately run the
benchmark. The PATH will not be updated yet, and their run stage will
not be able to find any of the necessary binaries. I'm not sure if there
was actually a requirement to log out/back in before running (e.g. a
bash_profile is only sourced on login, so did you have to install then
reboot?!), but this fixes all of those issues as long as the 'source'
command is available
gitignore the results directory

It's unclear to me why this was not already being done. Am I missing
something obvious?!
Fixes bug with install then run in one command

Forces reload of .bash_profile
Also removes code that requires ~/FrameworkBenchmarks download directory (see #578)
Dont restart databases if current test type does not use databases

This should speed up the benchmarks for people only interested in
test types that do not require the database machine to be online,
such as json and plaintext
Cleaning parser code formatting, and printing SSH strings if verbose

 - Print summary of SSH connection strings if verbose flag supplied
 - Guess current username
 - Clean up parser command line options. I should split this into
   multiple commits
 - Refuse to start benchmark if no client username is provided
Minor bug fix when setting CPU performance
Add in docker command line argument
gitignore command-line flags file benchmarker.cfg
Add apt-get 'yes' flag for large install

I had some issues where just piping in yes didn't get the job done.
Is there any reason not to do things this way?
Port mapping works
Install npm to server for nodejs test
Dynamically update PATH if bash_profile did not source
Faster test gathering

Replaces os.walk with glob
Addresses #614

Conflicts:
	toolset/benchmark/benchmarker.py
Decides to restart/not restart databases depending on test type

This is simply cleaning up a prior improvement using some new functions that were
added to the FrameworkTest
Add --noverify option to speed up benchmarking

This is useful if you know the verification will succeed/fail.
Also, the verification step currently has no impact on the
benchmark running or not running, so if you’re paying for CPU time
let’s not waste it on a no-op