- removed obsolete code that did support string exceptions
- some related cleanup

Remove change entries for changes already found in 2.12. No need for duplication until we hit a 2.13.0 final release

Updated to the latest zope.testing and backport the deprecation avoidance changes for zope.testing.doctest

  
 fixes lp:143013 on trunk

 fixes lp:143013 on this branch

- re-synced Test.publish_module with Publish.publish_module_standard

Update to new i18nmessageid to get the memory leak fix. The other changes in the 3.5.x series are all fully backwards compatible

In previous Zope versions string exceptions were used and all exceptions
re-raised. This doesn't work with each kind of exception, but we can still do
it with Unauthorized exceptions. This way the special handling for Unauthorized
exceptions works again, HTTPResponse._unauthorized is called again. This is now
done after rendering to make sure we don't break logging and custom views.

In previous Zope versions string exceptions were used and all exceptions
re-raised. This doesn't work with each kind of exception, but we can still do
it with Unauthorized exceptions. This way the special handling for Unauthorized
exceptions works again, HTTPResponse._unauthorized is called again. This is now
done after rendering to make sure we don't break logging and custom views.

  
Such cookies violate RFC 2965 / 2616.
  
Fixes LP #563229.

Such cookies violate RFC 2965 / 2616.

Fixes LP #563229.

It is very unlikely that v is a tuple and 'hasattr(sys, 'exc_info')' is always true.

- *Broken* because re-raising doesn't work with more than one required argument. "Needs to be able to take more than two arguments" was a wrong assumption.
- *Useless* because the code below never tries to re-raise rendered errors. That's the reason why the wrong check never caused trouble.

'handle_errors' is *always* true at this point because otherwise the error would have been re-raised in line 270.
Removed the raise statement because it was unreachable.