Add l3 db migration for plugins which did not support in folsom

Bug 1153585

Several plugins added l3 support in the grizzly release. This means that
when upgrading from the folsom data model, the relevant data model changes
should be applied.
In order to do so this patch refactors the initial migration in order
to be able to reuse the upgrade_l3 and downgrade_l3 routines.

Change-Id: I876f6d637665e10fb09d2084bb8a545ce469fbf3
Fix detection of deleted networks in DHCP agent.

The DHCP-agent uses an in-memory networks cache to find out which networks must
be deleted and which ones must be updated. In a case of agent restart the networks
cache is empty and it's not possible to cleanup DHCP-processes serving networks
which were deleted while the DHCP-agent was down. The proposed fix fills the networks
cache when the agent starts using a list of networks which have existing config files.

Fixes: bug #1135948
Change-Id: I27758389755cd19bca9fdbeda9cc1a123370f527
Adds Grizzly migration revision

fixes bug 1154255

This change adds a no-op migration called grizzly.  Deployers can reference
the symbolic name when updating their databases from Folsom.

Change-Id: I442586f1efdb52b7ec8b318077ace52f570b3ae4
Merge "Adds Grizzly migration revision"
Merge "Fix detection of deleted networks in DHCP agent."
port_security migration does not migrate data

The port security migration previously created the correct table structure but
it did not migrate the old data into this table. This patch adds code that
copies the id fields from networks and ports into portsecuritybindings
and networksecuritybindings tables.

One thing to note is that in grizzly when a port is created on a network that
has port_security_enabled=True, the port will also be created with
port_security_enabled=True. But since ports in NVP were not previously
created with the mac/ip security address pairs we have to set existing ports
and networks port_security_enabled value to be False. One could easily
write a script to set these values to True after applying this migration.

Fixes bug 1153366

Change-Id: I8a1ccab3e432c23c475816111d388df7f81b8e4a
Imported Translations from Transifex

Change-Id: Ifaa2da10298d2022dc4639e44be1cc6815c4661a
Merge "Add l3 db migration for plugins which did not support in folsom"
remove references to netstack in setup.py

bug 1154388

Change-Id: I1265b93edaa997405909e6e3dc408f365f2043e9
Ensure port get works when NVP mapping not stored in Quantum DB

Bug 1153616

If the entry for the mapping between a quantum and a NVP port identifier
is not found in the Quantum DB, search the port on NVP, and, if found,
add the mapping entry.
This ensures upgraded folsom databases keep working with Grizzly code.

Change-Id: I74943e8271f522dcd21c1c34b0159dd61bb66e76
Merge "remove references to netstack in setup.py"
Merge "port_security migration does not migrate data"
Merge "Ensure port get works when NVP mapping not stored in Quantum DB"
First havana commit.

This commit indicates that the master branch has moved on to
representing the "havana" release.  The previous commit will be use to
start the milestone-proposed branch for grizzly.

All future changes for grizzly must first be merged
into master, and then back-ported to a grizzly milestone-proposed branch
(or once grizzly is released, the stable/grizzly branch).

Change-Id: Ic2fadf815fd13d8c3d0afbc6493f8cd3ea6545d2
Merge "Imported Translations from Transifex"
Merge "First havana commit."
Add bulking support for Cisco plugin

For each bulk request, the Cisco plugin will handle the call,
and, through the base class method, convert them into a series of
non-bulking calls wrapped in a transaction (emulated bulking).

Those non-bulking requests will all be forwarded to the Cisco
model (VirtualPhysicalSwitchModelV2), which will either handle
the request locally (as in create_port), or delegate the request
to the OVS plugin (OVSQuantumPluginV2).

As a result, the model should not receive any bulking calls.
However, the model was set up to delegate any bulk calls to the
OVS plugin (which would act like the existing code, in case we
decide later to pass along any bulk calls). An alternative would
be to raise an exception, if a bulk call was made to the model.

Prior to this change, all bulking calls were forwarded from the
Cisco plugin to the model plugin, which would would delegate
(directly or indirectly) to the OVS plugin. The OVS plugin would
turn the request into a transction of non-bulking calls.

The effective difference proposed is that the create_port will now
create the port in OVS and then create the network in the Nexus
plugin.

The Nexus plugin does not currently handle bulking so this commit
is implementing emulated (versus native) bulking.

This patch has been updated with latest from upstream (Havana).

blueprint bulk-api-cisco-plugin
Change-Id: I874295b32ea20c2ca393228b0893a9dd6c77baf2