Neutron/ServiceTypeFramework

The intent of this document is to clarify and organize notions around so-called "Service Types". It describes entities and corresponding workflow.

Service Type Framework serves two main purposes:
1. Allow tenant to specify vendor (or service provider) for the requested service
2. Allow admin to offer different kinds of service insertion models of the services

Notions of Service Type Framework

1. ServiceType
type of the service: loadbalancer, firewall, vpn, etc.
This is more or less static set of string values that are currently residing in quantum/plugins/common/constants.py
These strings are used as keys in plugins dictionary when dispatching PEST API calls.

2. ServiceTypeProvider
This is a pointer to particular driver that implements some service.
Currently it has form ServiceType:PluginClass:DriverClass, where PluginClass and DriverClass are class paths that are loaded by quantum.
A set of service type providers should be used by service plugin to load drivers. TODO: if the model is single plugin per service type (like it is now), then it should be simplified to ServiceType:DriverClass
TODO: decide, if the set of ServiceTypeProviders needs to be dynamically configured.
Looks like there's no need for that, so it could be provided in configuration file in a form of string list.

3. ServiceGroup
Main intent of this entity is to express specific type of insertion for the group of ServiceTypeProviders.
In other word ServiceGroup is a list of ServicesTypeProviders that could be inserted in a certain way.
ServiceTypeProvider could be included in several ServiceGroups. In DB terms in means M:N relationship.

4. Insertion model
Just like ServiceType is should be a static set of string values: L2, L3, etc

Workflow for a user

In order to request specific vendor or insertion model, user does the following steps:
1. Chooses ServiceGroup from list of available groups.
2. Chosen ServiceGroup specifies a set of ServiceTypeProvider for the given service. (Ima