extension framework should support extended attributes on core resources

Quantum API extensions such as https://blueprints.launchpad.net/quantum/+spec/provider-networks add extended attributes to the request and response messages of existing core resource actions (create, get, get collection, update, delete). This category of extension is implemented within a plugin, typically exposing details of how the plugin maps core API virtual resources to physical networking mechanisms.

The existing quantum.extensions.extensions.RequestExtension mechanism is not satisfactory for this category of API extension for several reasons. First, its handler function is executed completely outside the context of the core API and the plugin's methods that implements the operations on the core resource. This handler function therefore needs to make separate calls into the plugin to get data to be returned in the response, resulting in extra DB queries, etc. Also, details from the request such as context, output field selections, and filter expressions are not readily available to the handler function. Finally, the handler function must de-serialize the core response message, add its extended attributes, and then re-serialize the message, which is inefficient and only works for JSON.

Instead, the core V2 API mechanism needs to know about the extended attributes so that they are handled similarly to the attributes defined in the core API (but scoped in the extension's namespace). This can currently be achieved by editing the quantum.api.v2.router.RESOURCE_ATTRIBUTE_MAP for request message attributes, and the keys tuples in the quantum.api.v2.views.<resource> classes for response message attributes. Once this is done, the extended request attributes are available (with defaulting and allow_put/allow_post checking) to the plugin's core API method implementation (i.e. in the network dictionary parameter passed into create_network), and the extended response attributes are copied (if present) from the dictionaries returned by the plugin's core API method implementations into the response messages. Thus, from the perspective of a plugin's core API methods, the extended attributes can be handled exactly like core attributes.

But extensions should not require modification of core code. Therefore a mechanism is needed by which an extension can register the extended attributes that it defines, so the same result is achieved. This mechanism would most likely result in the extended attribute data being added to the RESOURCE_ATTRIBUTE_MAP used in processing input messages, and to the lists of keys copied from returned dictionaries to response messages.