Without this, sending an interrupt signal (hitting Ctrl+C) during a
chef-client run that is currently executing a resources that has
`retries` set will not interrupt the run, although the interrupt handler
set up in Chef::Application calls Process.exit, which raises SystemExit.
If the retryable resource is shelling out, the spawned process also gets
the INT signal and will stop -- however, the chef-run would go on,
merely noticing that the resource has failed and theres X-1 retries
left.
It is imaginable that users depend on some (whacky) Ruby script in a
retriable resource that raises SystemExit, and they want this to _not_
stop the chef-run. So it's up for debate if we just want to merge this
or make it configurable.
In general, I'd like Ctrl+C to _stop my chef-run_, but this expectation
could also be misled.
When adapting tests to this change, it became apparent that for some
reason the runner_spec.rb test didn't behave as expected. I've thus made
those tests a little stricter by replacing some allows by expects.
Signed-off-by: Stephan Renatus <srenatus@chef.io>