Nova/PortingAPIExtensionToV3

Porting a V2 API extension to the V3 API
Note that it will be significantly easier for people to review porting changes if you split the patch into two changesets: This will allow people to see just the changes required rather than an entirely new file
 * In the first just copy the extension and test files unchanged to the v3 directories
 * In the second make the modifications required for the V3 API framework and any other API fixes

Checklist
 * Checks before starting porting work on an extensions
 * Check the V3 API Work list to see if anyone else is already working on porting the extensions
 * https://etherpad.openstack.org/NovaV3ExtensionPortWorkList
 * Add your name to the work list indicating that you are working on the extension before starting work on it
 * Check to see if it is an extension which we are intentionally not porting to the V3 API
 * Volume related functionality which can be directly accessed via Cinder is not being ported
 * Network related functionality which can be directly accessed via Quantum is not being ported
 * Things to look for when porting an extension
 * Is this in the list considered for moving to part of the core API?
 * https://etherpad.openstack.org/NovaV3APICore - may need to seek out further consensus on mailing list/Nova meeting
 * This will change the ALIAS for the extension (eg does it start with os-), but little else
 * Should the functionality in this extension be merged with another extension?
 * Some extensions have in the past been added merely because we couldn't modify existing extensions and logically the functionality belongs together with another extension
 * Do the methods follow REST principles
 * eg PUT MUST be idempotent
 * Rename policy name for the extension
 * The policy auth name should be the extension ALIAS prefixed with v3: - eg instead of "fixed_ips" it should be "v3:os-fixed-ips"
 * Is the JSON input/output format consistent with the XML input/output format
 * eg parameter names are consistent
 * Does the V2 version of the extension have any hooks in servers.py (eg need to modify flags for creating an instance). Looks in v3/servers.py
 * Use or add if doesn't already exist an extension point so it can be done without any extension specific modifications to servers.py
 * Python style attribute names
 * eg imageRef -> image_ref
 * Remove updated field, add a version field (see v3/fixed_ips.py as an example)
 * Are there actions which should instead be methods
 * Add expected_errors decorator for each method which declares what the expected HTTP status codes returned from each method are
 * This relies on https://review.openstack.org/#/c/30045/ getting merged first though
 * Unittests must be ported as well of course
 * Make sure that the test file is importing the v3 version of the python module :-)
 * Will need lots of v2 -> v3 renaming of paths
 * Will need to remove the project_id/tenant_id from the path
 * wsgi_app will need to be changed to wsgi_app_v3 or the test will run against the V2 API