bump API version to v2

[jmartin-sul]

#1306 technically broke semver conventions, because it introduced a change to the API which was not backwards compatible with prior usage (new requirement for a valid token in the Authorization header). per discussion on #1306, here's a plan to fix that incrementally, without disrupting running services or shutting down accessioning/preservation; tickets in other repos that require changes can be spawned as needed:

Prescat part one - backwards compatibility

• add the v2 routes (pointing to the same controller methods) to pres cat and have the redirects in routes.rb (for un-versioned calls) default to v2 instead of v1 in a branch
  • test this branch in stage with consumers
  • merge and deploy this backwards compatible prescat in prod if no problems

preservation client

• four client consumers:
  • preservation_robots
  • dor-services-app (may be used by argo or common-accessioning - test before those)
  • argo
  • common-accessioning
    steps:

• create a branch of preservation-client to use v2 instead of v1.
• client consumers* each get a branch to use branch of gem
• client consumers deployed to stage
• if no problems, do all of this avoiding deployment mondays
  • merge branch of preservation-client
  • release preservation client gem
  • update client consumers branches to use newly released gem
  • deploy client consumers branches to stage and test again
  • if no problems, merge client consumers branches
  • deploy client consumers to prod

Prescat part two - v2 only

(the upgraded clients should already be using v2, and turning off v1 should not affect them.)
Either:

• remove the v1 routes in this application, and the legacy redirects for un-versioned routes in a branch
• test this branch in stage with consumers
• merge and deploy this backwards compatible prescat in prod if no problems

OR:

• look at prescat API logs (on prod-01) to ensure that there are no v1 requests being made
• remove the v1 routes in this application, and the legacy redirects for un-versioned routes in a

[jcoyne]

@jmartin-sul I would consider not doing this. While semver is important for public libraries and APIs, this is a private api and we control all consumers. Doing this is going to add a bunch of work for little benefit to our users.

[jmartin-sul]

@jcoyne that's totally fair, and is also why i didn't put it in the ready column on the zenhub board. i was pretty on the fence about whether the version bump was worth it, and while i think it's a good thing to capture for possible future maintenance, i def wouldn't advocate to get it done in this work cycle.

if you or others feel strongly that we should just close this issue and take it off the table, i'd be fine with that too. my preference for doing this is pretty slight.

[jmartin-sul]

@jcoyne i moved the issue to "out of scope" on the ZH board to make it clear it shouldn't be picked up for now