Improve usage of MagicMocks in ML2 and L3 tests

Removes usage of a MagicMock in a case where it's not needed.
Replaces a manual function replacement with a mock.patch call
so it's correctly cleaned up by mock.patch.stopall.

Partial-Bug: #1316401
Change-Id: I8f2f7e9eca2aeaa3b65be1b451e96ed2146950f4
Changed DictModel to dict with attribute access

DictModel is a dict where keys are accessible via attribute access.
The old version was an object with attributes created from dict keys and many
attributes where accessible only via getattr because they did not have a valid
python attribute naming (i.e.: 'provider:network_type' is not a valid
python variable/attribute name)::

    >>> d.provider:network_type
      File "<stdin>", line 1
        d.provider:network_type
              ^
    SyntaxError: invalid syntax

This time we just subclass dict with attribute access to keys.

So dict keys are accessible via attribute access but remain accessible via key
access::

    >>> d = DictModel({'foo': 'bar', 'provider:network_type': 'something'})
    >>> d.foo == d['foo']
    ... True
    >>> getattr(d, 'provider:network_type') == d.get('provider:network_type')
    ... True
    >>> getattr(d, 'provider:network_type') == d['provider:network_type']
    ... True

One of the big advantages when debugging is that now in pdb, pp(d) (where d is
a DictModel instance) shows a nice dictionary structure, while with the old
version whe had to perform a "dir(d)" and introspect each attribute...

Change-Id: I05fad7cd9763f97f61680d45e1b6592a80049541
Closes-Bug: 1251653
ofagent: Fix VLAN usage for TYPE_FLAT and TYPE_VLAN

while ofagent uses OF1.3, the current coding incorrectly uses
OF1.0 terms in some places.  namely, _local_vlan_for_flat uses
0xffff to mean "no VLAN".  it should use OFPVID_NONE and
pop_vlan/push_vlan appropriately.  the same problem exists for
reclaim_local_vlan.

Closes-Bug: 1301144
Change-Id: I3df821fd72471f8bd84366e3b5a1cc7e3489156c
Monkey patch threading module as early as possible

In oslo.messaging, local thread store is used to pass RPC request
context [1]. If we try to import oslo.messaging before monkey patching
threading library, it attempts to access unpatched storage and fails
with AttributeError.

[1]: oslo/messaging/localcontext.py#L26

blueprint oslo-messaging

Change-Id: Ied7302fcb1d3e14428540e39e3db704550027890
Refactor code in update_subnet, splitting into individual methods

The update_subnet was already long and complex enough and adding
more code to it was undesirable, after commit

I47a3a71d0d196b76eda46b1d960193fb60417ba9

Hence this refactor splits parts of the update_subnet code into
dedicated sub-methods.

Change-Id: I8f98938da88db287290493dc0daf7c81b8b5f542
Support Subnets that are configured by external RAs

The IPv6 attributes for subnets provides support for IPv6 subnets that
are managed by non-OpenStack gateway devices, by creating a subnet that
has the ipv6_ra_mode attribute not set, and the ipv6_address_mode
attribute set to IPV6_SLAAC.

In order to support stateless IPv6, Neutron should calculate an IPv6
address based on the IPv6 prefix and MAC address via EUI-64 specification,
and assign this address to the port.

Implements blueprint ipv6-provider-nets-slaac

DocImpact

Change-Id: Ia76d76a67e0dc9f996a72e38d987a05aecc1b55f
Co-Authored-By: Xu Han Peng <xuhanp@cn.ibm.com>
Co-Authored-By: Dazhao Yu <dzyu@cn.ibm.com>
Ensure routing key is specified in the address for a direct producer

This change is already merged in oslo-incubator.  Original commit
message body includes:

    Porting this fix from oslo.messaging.  This fixes the impl_qpid.py
    driver to allow it to work with the latest stable upstream QPID broker
    (version 0.28).  See the Apache Qpid Jira bug
    https://issues.apache.org/jira/browse/QPID-5557

Change-Id: If71f78e50f8a9b3acfd1e9d02c8271f17c4ebee7
Related-Bug: #1300318
Check the validation of 'delay' and 'timeout'

In health monitor, the 'delay' should be greater or equal than 'timeout'.

Change-Id: I64972881676f2a1269aad8f9cdc77ae957c088d9
Closes-bug: #1320111
Fix race condition with firewall deletion

In some cases when firewall is created and then deleted in short
period of time, there could be a race condition of firewall status
changes. Agent may change firewall status from PENDING_DELETE to ACTIVE
because the agent has just set it up on the backend.
Delete request then is not properly served and firewall remains in ERROR
state and can't be deleted at all.

To fix this changing status from PENDING_DELETE is not allowed.
Deleting firewall in ERROR state is allowed.

Change-Id: Iec3cfcb1e03b33dda8e1f10ca51bd9b61fa8030d
Closes-Bug: #1328162
Merge "Monkey patch threading module as early as possible"
Merge "Ensure routing key is specified in the address for a direct producer"
Merge "Check the validation of 'delay' and 'timeout'"
Merge "Refactor code in update_subnet, splitting into individual methods"
Merge "Changed DictModel to dict with attribute access"
Merge "Improve usage of MagicMocks in ML2 and L3 tests"
Merge "Fix race condition with firewall deletion"
Merge "ofagent: Fix VLAN usage for TYPE_FLAT and TYPE_VLAN"
Merge "Support Subnets that are configured by external RAs"