Send DHCP notifications regardless of agent status

The Neutron service, when under load, may not be able to process
agent heartbeats in a timely fashion.  This can result in
agents being erroneously considered inactive.  Previously, DHCP
notifications for which active agents could not be found were
silently dropped.  This change ensures that notifications for
a given network are sent to agents even if those agents do not
appear to be active.

Additionally, if no enabled dhcp agents can be found for a given
network, an error will be logged.  Raising an exception might be
preferable, but has such a large testing impact that it will be
submitted as a separate patch if deemed necessary.

Closes-bug: #1192381
(cherry picked from commit 522f9f94681de5903422cfde11b93f5c0e71e532)

Change-Id: Id3e639d9cf3d16708fd66a4baebd3fbeeed3dde8
Merge "Send DHCP notifications regardless of agent status" into stable/havana
Avoid loading policy when processing rpc requests

When Neutron server is restarted in the environment where multiple agents
are sending rpc requests to Neutron, it causes loading of policy.json
before API extensions are loaded. That causes different policy check
failures later on.
This patch avoids loading policy when creating a Context in rpc layer.

Change-Id: I66212baa937ec1457e0d284b5445de5243a8931f
Partial-Bug: 1254555
Don't allow qpid receiving thread to die

This patch is a partial backport of
22ec8ff616a799085239e3e529daeeefea6366c4 in oslo-incubator.

https://review.openstack.org/#/c/32235/13

This patch ensures that the thread created by consume_in_thread() can
not be killed off by an unexpected exception.

Related-Bug: #1189711

Change-Id: I4370045b450b2b4b9b3bde1f6f3654cdecc722e2
Remove and recreate interface if already exists

If the dhcp-agent machine restarts when openvswitch comes up it logs the
following warning messages for all tap interfaces that do not exist:

bridge|WARN|could not open network device tap2cf7dbad-9d (No such device)

Once the dhcp-agent starts it recreates the interfaces and re-adds them to the
ovs-bridge. Unfortunately, ovs does not reinitialize the interfaces as they
are already in ovsdb and does not assign them a ofport number.

This situation corrects itself though the next time a port is added to the
ovs-bridge which is why no one has probably noticed this issue till now.

In order to correct this we should first remove interface that exist and
then readd them.

Closes-bug: #1268762

Change-Id: I4bb0019135ab7fa7cdfa6d5db3bff6eafe22fc85
(cherry picked from commit b78eea6146145793a7c61705a1602cf5e9ac3d3a)
Multiple Neutron operations using script fails on Brocade Plugin

Closes-Bug: 1223754

Change-Id: Ifdeed8407a1cb3df9f17267ea582caab385a63f3
Merge "Multiple Neutron operations using script fails on Brocade Plugin" into stable/havana
Merge "Don't allow qpid receiving thread to die" into stable/havana
Fix passing keystone token to neutronclient instance

Neutron client expects token to be passed as token= argument, while
neutron-metadata-agent passes auth_token= instead. This effectively makes the
client to authenticate against keystone each time it's instantiated. In
neutron-metadata-agent case, it means 'each time a client sends a metadata
request.'

The issue results in high cpu utilization on keystone side when simultaneously
invoking multiple nova instances with cloud-init.

Change-Id: I2a31f9c0c3cfa915975ecc53d71168a3895528d8
Closes-Bug: 1274487
(cherry picked from commit 3799efe792700e7736666c40cc42c265eee09230)