Remove Finder API integration

Now that Finder Frontend is pulling results from Rummager we don't need
to update Finder API when documents are publishing nor withdrawn.
Handle GdsApi HTTP error types

Instead of rescueing from specific HTTP errors raised by the panopticon registerer. Instead rescue from GdsApi::HTTPErrorResponse types
Reraise panopticon publication errors for worker

Re raise any errors created by the PanopticonRegisterer in order to catch them in the worker. This is something we would like to change. wrapper classes around the gds-api-adapters should handles errors and error logging themselves in the future. There is thought towards allowing the API wrappers to an object which stores the state of the publishing (PublishingTask maybe?) which could be handed to the worker in order to query the state of a particular publishing job. This would allow us to correctly raise an error in the worker without frivolously catching GdsApi exceptions and making the worker unaware off GdsApi.
Remove ManualDocumentObserversRegistry

There are no observers for manual documents, so just get rid of it.
Stop exporting manual sections to Panopticon

Only the manual itself needs to be exported to Panopticon for the
purposes of tagging with Organisation and Specialist Topics which allows
it to be included in specialist browse pages.

We have to continue exporting manual change notes for now in order to
register their route. When we changed manuals to be exported to the
Content Store instead of Content API we moved change notes to be part of
the details hash of the manual itself, rather than being a stand alone
document. That means Content Store isn't registering the route for the
change notes. Leaving the Panopticon registration in is a workaround and
should be addressed in the future.
Merge pull request #252 from alphagov/remove-finder-api-integration

Remove Finder API integration
Fix typo in rummager stub and message reset

This did not fail or raise an error because:

 1. `rummager_api` is a method in the wiring
 2. The wiring is included in the entire cucumber World
 3. The tests using this were then matching original requests.
Add help for collapsibles

This help is only required for collapsible sections on manuals so add in a yield to format specific help and pass in the help from the manuals edit page
Merge pull request #259 from alphagov/add-collapsable-info

Add help for collapsibles
Merge pull request #258 from alphagov/fix-republishing-test-typo

Fix typo in rummager stub and message reset
Merge pull request #256 from alphagov/feature/robustify-manual-publishing

Robustify manual publishing
Merge pull request #257 from alphagov/remove-manual-sections-panopticon-integration

Remove manual sections panopticon integration
Abstract common Document observers registry code

Observers should be the same for all SpecialistDocument types, so let's DRY up the code here.
Add exporter and formatter for email alerts

Following the patern of

* Things that send data to an API = Exporter
* Things that an exporter uses to format for an API = Formatter

The EmailAlertExporter exports formatted emails to the GovUkDelivery API
Add EmailAlertExporter to publication observers

Wire up the EmailAlertExporter in the publication observers chain for SpecialistDocuments. This should be the last thing in the chain so that we only notify users of a new SpecialistDocument publication once it is fully available on the frontend.
Features to test publication alert workflow
Move Publication alert formatting into a view

|Instead of rendering text directly in the Formatter, use ActionView to render an erb view.
Add more meaningful copy to the publishing email

In order to allow human readable copy to email alert we need to provide some custom humanized attributes to the formatters. Instead of binding the formatters to the schema instead we will subclass the formatters to provide this information
Ensure that a topic exists before publishing to it

In order to create a new publication email we should ensure that a topic exists in the publication api before trying to export a notification for that topic.
When republishing, dont send email notifications

When republishing from a script we do not want to notify users. Instead use a separate set of observers in order to republish documents in the system.

This is a system only journey and is non user facing!