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.
Add association for Manual and PublishTask

This commit adds an association marshaller between Manual and PublishTasks allowing us to make the most recent PublishTask available to the specialist-publisher frontend for feedback on how far the publishing task is from completion.

This association is read only!
Provide feedback of state of publishing manuals

Display a user centred message to notify the user of where the PublishTask is in the queue so that they are aware that when they press 'Publish' that there will be some time before the item is "published".
Assure errors are raised when recoverable errors occur
Log version mismatches when publishing manuals