Merge master into develop

[dazza-codes]

This PR merges master into develop because the develop branch is both behind and ahead of the master. It pulls our recent PRs into develop to resolve all the conflicts in these branches. Once this PR is merged into develop, the next step should be a painless merge of develop into master (hopefully a fast forward).

There is only one new commit in this PR (see 4b00871 for details of the Gemfile.lock changes). The rest of the commits are either existing commits in master and/or develop, see https://github.com/sul-dlss/sdr-preservation-core/branches for the counts.

The details were:

git fetch -ap
git checkout develop
git checkout -b develop-merge-master-201706
git merge master
# the only conflict was in Gemfile.lock
# used all the latest gem versions (mostly just minor/patch version differences)
# checked the result with a bundle install, a-ok
git add Gemfile.lock
git commit  # just use the auto message
git push # with set upstream details

@jmartin-sul - please consider this option as a simpler alternative to #56

[coveralls]

Coverage remained the same at 70.314% when pulling 4b00871 on develop-merge-master-20170627 into 8206527 on develop.

[jmartin-sul]

this seems like a reasonable approach. less slogging through conflicts, which is nice. i think the Gemfile.lock changes here are slightly more conservative than the PR i put up, which is fine.

i used the delete-and-regenerate Gemfile.lock approach because i'm always very hesitant to manually merge or edit Gemfile.lock, and usually try to let bundler generate it. that said, as you pointed out, bundle install seemed fine with the resultant Gemfile.lock here, so i guess all's well.

one concern that i have about this PR is that the commit history is even longer and messier than the one on #56.

but one comforting observation is that the diff of this branch against master looks substantially similar to the diff of the branch in #56 against master:
https://github.com/sul-dlss/sdr-preservation-core/compare/develop-merge-master-20170627
https://github.com/sul-dlss/sdr-preservation-core/compare/develop_try-rebase-2017-06-26

i also just tested merging this branch back into master (locally on my laptop). and that does allow a fast-forward of master, and the diff between that updated master and current github master looks like the diff of this PR's branch against master (see first link above). which is what was expected/hoped for, i think:
https://github.com/sul-dlss/sdr-preservation-core/compare/master-updated-from-develop-after-master-merged-to-develop

so, i dunno, i'm fine to go with either approach (merge the PR i put up last night, or close that, and merge this one, and then merge updated develop to master).

maybe someone who's a bit more of a git expert can weigh in on what will ultimately leave the history in a better and more usable state? i usually go to @atz for this sort of advice.

[dazza-codes]

I think this merge is the way to go; either via merging this PR or it might be more direct to do it on the develop branch directly rather than via a PR.

The commit history in this should be just the commits on master that the develop branch is behind on. The master branch has a few recent commits/PR-merges that resolve conflicts and therefore make this PR easier and the next merge of develop->master a FF. So I'm OK with the commit history and we could possibly do a cleanup when everything is in master and we know what we're dealing with.