Open Stack

In https://review.openstack.org/#/c/496212 I've started the process
of moving some of the generally useful microversion-related
functions out of the placement service and into the microversion-parse
library. This will help make the library more useful (see the
README.rst in the review for examples).

I have, however, thus far left out some of the serious microversion meat
that is still in use in placement:

* decorator for handling mulitple callables of the same name based
   on microversion
* utility method to raise a status code response based microversion
   match (things like: respond with a 404 if the microversion is less
   than (1, 1))
* middleware that extracts the microversion from headers (using
   microversion-parse), sticks it in the environment, and sends
   microversion headers on every response

The reason these are not included is because all of them use webob,
primarily in two different ways:

* raising webob exceptions within a webob.dec.wsgify context,
   causing well formed error responses
* using a json formatter to structure error responses according to
   api guidelines

I'm hesitant to add these because they would introduce a dependency
on webob and enforce some behaviors in the projects that use them.
The options seem to be:

* Don't worry, nobody but nova and placement is using
   microversion-parse and nobody else has plans to do so.
* Don't worry about it, everyone loves webob, include it.
* I _think_ I can keep the use of webob contained in a way that makes
   sure it doesn't impact the rest of the WSGI stack (less sure
   about the error formatter).
* With some more effort I could do raw WSGI handling, leaving out
   the use of webob stuff.

I'm kind of inclined towards the last option, but I'm not sure it is
worth it if there aren't any interested parties.

To be clear, if I move the missing parts mentioned above into
microversion-parse, what it could then become is a generic
microversion handling library, including WSGI middleware, satisfying
most common microversion needs. If I don't move them, it's still
useful, but projects would still need to write their own middleware.
Given the diversity of stacks we have in use, that might be how it
would have to work anyway.

-- 
Chris Dent                      (⊙＿⊙')         https://anticdent.org/
freenode: cdent                                         tw: @anticdent