Preserve browser viewport scroll when clicking on a bootstrap tab

Without this we were always scrolling to the top of the page, this way clicking a tab doesn't change the browser scroll, which is less surprising.
Add something to allow us to validate a bulk upload zip file

BulkUpload::ZipFile - adds a requirement on unzip (we already required zipinfo for AttachmentUploader so I don't suppose this is too bad).  It looks at the zip file to see if it's too big, or if it isn't actually a zip file.
Add UI on bulk uploads, and controller response to that UI

We render 2 tabs in the attachments section.  One is the original attachments UI (we call this "individual upload"), the other is a new "Bulk Upload" UI to allow uploading a single zip file.

The tabs are a bit odd in terms of JS, because I want them to be form controls that record the users intent rather than just links.  The controller response is based on which radio button is selected.

If the bulk upload button wasn't selected then we do nothing.  If it is we look at the bulk_upload_zip_file params.  If those params mean the BulkUpload::ZipFile instance is invalid we re-render the form instead of committing the action.  If it's valid, we will proceed to commit the action (there's more to come here to deal with the actual contents of the zip file).

Rationale for this is that when the user has javascript off the form will still work.  A future commit can enhance the bulk upload UI to use AJAX and hit a separate endpoint that only redraws the form.
Turn the bulk upload zip file into params for manipulating attachments

First we remove any edition_attachments_attributes - because choosing to do a bulk upload trumps anything you might have done on the "individual upload" section.

We extract the files from the zip file and look at the attachments on the edition instance in question.  For each file that doesn't match the file name of an existing attachment we turn this into a set of params for adding a new edition_attachment instance.  For each file that does match the name of an existing attachment we turn this into a set of params for replacing the attachment_data of the that attachment.

We then let the action continue on as normal.
Uploading a zip file of bulk attachments forces a review of changes

Added a new method to Attachable (force_review_of_bulk_uploads), calling this gives the model a new attribute (attachments_were_bulk_uploaded).  Setting this attribute to something causes a validation error suggesting that the user review the bulk upload changes.  In BulkUpload::ZipFileToAttachments#manipulate_params! we set a value for this attribute in the params.

We call force_review_of_bulk_uploads on DetailedGuides and Publicationesque edition types.
Factory-built users now have a uid

Without a uid a factory built user cannot be persisted to the session by GDS-SSO.  Our tests would still work because the mock_gds_sso strategy for warden is to always authenticate using the first available user, or whatever is in GDS::SSO.test_user.

We found this because most public facing pages don't actually ask warden to try and log someone in, they just ask if there is already someone there.  If the request to a public page wasn't the first request in the test it would fail because there was nothing in the session.  If it was first it only worked because the Warden::Test::Helpers#login_as helper drops something into warden to say "on the next request, pretend this user is in the session".
Individual upload should be the default position

Also update cukes to make sure we are always explicitly choosing individual upload, just in case.
Fix cuke broken by new, working, auth on public pages.
Make the bulk uploader zip file extractor ignore OS X resource forks
Log out to test that old attachments redirect to their replacements

This broke because when we fixed the user factory to allow users to be persisted in the session properly, it meant there was now a user available to see if the attachment belonged to a visible edition.  Anyone that can log in to inside gov is allowed to see any edition of a document (so that preview works) and so, they could see the old attachment because it belonged to an archived edition.  If we logout before trying to see the redirect we get the expected behaviour.

Not saying that this is right, I just wanted the build to be green.  We may need to further think about how we do attachments and urls.
Describe desired bulk upload behaviour

Also implemented the feature fully.  We can choose "Bulk upload" and send a zip file, this then returns the form again forcing us to review the changes made to the attachments by the contents of the zip file.  We review and fix any errors with blank meta-data on new ones and then save the document.
Don't use /tmp for bulk upload zip extraction

Made it configurable via BulkUpload::ZipFile.default_root_directory (much like Whitehall::Uploader::AttachmentCache).  Use an initializer to set it to Rails.root.join('bulk-upload-zip-file-tmp').  We'll use puppet to make this a symlink to a big data store on production.

Configure it during tests to use a different dir and get rake test:cleanup to remove it.
Merge pull request #155 from alphagov/bulk-upload-of-attachments

Bulk upload of attachments