Keep details of original errors where possible

Instead of raising a new error with the same code as the original, re raise the original error keeping all of its details in tact.
Add inheritance layer to specific http error types

Rather than forcing specific applications to handle error codes and translate these to meaningful HTTP error types. Let gds-api-adapters handle raising errors of specific types instead.

By allowing the api adapters to raise specific ranges of HTTP error code, in specialist-publisher we can now use this to handle certain types of error more easily. In the case of queued publishing we would like to retry a publish if a HTTPServerError occurs, for example a 503 response, as this could be recovered from in a few moments allowing the publishing task to complete without intervention. A client error however, such as a 403, would mean that this publish task will never complete and therefore publishing should be aborted immediately.

This change should be transparent to other applications as this is merely an extra layer of inheritance to the inheritance chain. All errors will still be a subclass of the HTTPErrorResponse type but will be more specific to the HTTP response code ranges.
This change should be transparent to other applications as this is only an extra layer of inheritance to the inheritance chain. All errors will still be a subclass of the HTTPErrorResponse type but will be more specific to the HTTP response code ranges.
Merge pull request #208 from alphagov/refactor/more-specific-error-handling

Add inheritance layer to specific http error types