Don't re-raise critical errors that occur while handling an error

This logic was added to satisfy pep-3333, where the error handling section
says application authors should "never trap errors raised by start_response
when exc_info is being provided".

However, this appears to be intended to prevent applications from catching
exc_info being re-raised by start_response(), which happens when an
application tries to send an error response (includes exc_info), but can't
as output has already been written to the client. These exceptions should
be thrown up to the server so it can abort the connection, not caught by
the application.

In this case, the start_response() call in question may be an error
response, but it's always the first call to start_response(), so should
never re-raise exc_info in this way. As such, the special handling is
unnecessary.

bottle.py

@@ -1106,7 +1106,6 @@ def _cast(self, out, peek=None):
 
     def wsgi(self, environ, start_response):
         """ The bottle WSGI-interface. """
-        provided_exc_info = False
         try:
             out = self._cast(self._handle(environ))
             # rfc2616 section 4.3
@@ -1117,13 +1116,11 @@ def wsgi(self, environ, start_response):
             exc_info = environ.get('bottle.exc_info')
             if exc_info is not None:
                 del environ['bottle.exc_info']
-                provided_exc_info = True
             start_response(response._wsgi_status_line(), response.headerlist, exc_info)
             return out
         except (KeyboardInterrupt, SystemExit, MemoryError):
             raise
         except Exception as E:
-            if provided_exc_info: raise
             if not self.catchall: raise
             err = '<h1>Critical error while processing request: %s</h1>' \
                   % html_escape(environ.get('PATH_INFO', '/'))