Publish manuals to the Publishing API

The Publishing API will eventually replace the Content API.
Publish manual sections to the Publishing API
Publish manual change notes to the Publishing API

Change notes are added to the 'details' attribute on the 'manual'
content item, rather than being a separate content item.
Send manuals organisation info to Publishing API

The Publishing API has no concept of tagging just yet, so the organisation
association is stored in the 'details' attributes.
Access manual/section attributes using fetch

This means that if the attribute is missing, an exception is thrown
(rather a null being sent to the Publishing API).
Use production Organisations API except in test

In dev, we don't want to incur the cost of depending on Whitehall just for the organisations API.
In test, the organisations API stubs assume that the basepath is `Plek.current.find("whitehall-admin")`.
In preview, the client would have to handle simple auth so pointing to production is simpler.
Calculate manual update type from section update types

A manual update is major if there are any major section updates.
Merge pull request #222 from alphagov/push_manuals_to_content_store

Publish manuals, sections and change notes to the Publishing API
Move logic of queueing publishing into a service

In order to keep our controllers clean, let's wrap our worker in a service in which we can add add extra queueing functionality such as adding states.

Serviceception?
We pass the context not the id!

This shouldn't work ever!
Make ShowManualService not require the controller

As with the SpecialistDocument services, factor out the controller context and instead pass id parameters directly
Make Create/Update Services not require controller

As with the previous commit factor out the controller requirement from the Create and Update manual services so they can be reused outside of the context of a controller
This should be type not typ

LOLZ!
Make QueuePublishService require repo

Make the QueuePublishService depend on the repository in order for the service to find our manual and return it for the controller. This will make logging easier in the future when we require the object.
Introducing the PublicationLogger

In order to abstract the PublicationLog class, lets create a PublicationLogger which takes a manual and a state. This allows us to '.call' the logger and isolate us from changes to the Mongoid API.
Only export change notes where publishing succeeds

As we are now introducing publishing queue states of manuals into the publishing log we should no longer create change notes for everything. PublicationLog has become more of a 'logging' utility for backend purposes while change notes are a user oriented version of content updates.
Add Sidekiq web interface in development

It's a little bit handy.
Only publish manuals if its the correct version

As we are now queueing manuals for publishing we need to protect against changes happening between an editor clicking Publish and the worker actually performing the publish.

We also add the version number to the logs as its useful information to know about.
Remove PublishLogger in favour of PublishingTasks

Instead of creating new log entries for every state of publishing, instead we are going to use publishing tasks as a way of telling the workers which manuals to publish.

There is no need to interact with the workers through a registry as we gain very little from this interface. Instead we can simply pass the worker class directly to the service and interact with it directly.

This means that PublishingLogs can now relate to a successful PublishingTask which will contain state of documents current publication.
Change PublishingTask state on error or success

When something fails in pushing to panopticon let the PanopticonRegisterer raise its own error. This will bubble up to the worker allowing us to rescue from specific error types. In the case of ClientError we should abort as this is unrescuable (ie duplicate slugs). In the case of a ServerError we should retry a certain number of times. In the case of any other error, we should abort.

All errors are logged with Airbrake in order to notify us of persistent failures in publishing.