1. Wait for the start callback rather than the do block, as it happens
   later. This prevents us from getting into many conditions where the
   start returns before the server is fully initialized, where if stop()
   is called too soon after start returns, it would cause exceptions.
2. Wait for the thread to finish completely
3. Use Thread.current.abort_on_exception` to show the actual listen errors,
   so that problems like this can be diagnosed.
4. Use :each to start and stop TinyServer so that race conditions like this
   are exposed earlier and more often (this will let us rid ourselves of them
   more quickly).
5. Use WEBrick::HTTPServer directly, which gets rid of the need for the
   complicated trap workaround (rack is the one that traps).

Generated via git ls-files | xargs perl -pi -e "s/(Author.*?<[^@]+@)(?:opscode\\.com|getchef\\.com)(>)/\\1chef.io\\2/gi"

Generated via git ls-files | xargs perl -pi -e "s/[Cc]opyright (?:\([Cc]\) )?((?\!$(date +%Y))\\d{4})(-\\d{4})?([, ][ \d]+)*(,|(?= ))/Copyright \\1-$(date +%Y),/g"

This is an entirely mechanically generated (chefstyle -a) change, to go
along with chef/chefstyle#5 . We should pick something and use it
consistently, and my opinion is that double quotes are the appropriate
thing.

This tests the reuse of the content length validation object and
the situation where the content length of a previous download is
retained while a 403 or other HTTP error fails to re-init the
content length to zero.  The result is the 403 is turned into an
inaccurate content length exception, masking the real error.