Add metadata_proxy_socket into configuration files

Change-Id: I76856c2f804be92fa8cc667b4653d2e5e58e422a
Fixes: Bug #1215261
Enable GRE and VXLAN with the same ID

Current packet processing in br-tun is based on tun-id,
as a consequence, two networks using different tunnel
types but sharing the same tun-id would not be properly isolated.

To ensure proper isolation within a single bridge, NORMAL action
can't be used any more as it floods unknown unicasts on all
bridges ports. It is replaced by a learn action that dynamically
sets-up flows when packets are recieved from tunnel ports. As mac
address are learnt in explicit flows (in table 20), we can use a
default action in that table to flood unknown unicasts to the
right set of ports, like broadcasts and multicasts packets.

See https://wiki.openstack.org/wiki/Ovs-flow-logic for a more
detailled explanation of the flow logic

Another alternative could have been to use distinct bridges for
each tunnel type (whithout modifying the current flow logic),
but previous alternative may be preferable as it paves the way
for new tunneling optimisations (like RPC based mac learning and
partial-mesh flooding proposed in bp/l2-population)

Change-Id: I1dfe74f96680c2c6fe4d8d4aac4821c6b020c005
Closes-Bug: #1196963
Imported Translations from Transifex

Change-Id: Iec84d6c1aced5c2cbd976f899811396f9f9e6753
Merge "Add metadata_proxy_socket into configuration files"
Merge "Imported Translations from Transifex"
Merge "Enable GRE and VXLAN with the same ID"
Add l2 population base classes

This patch initiates the blueprint l2-population

OVS & LinuxBridge drivers will be added as dependencies.

Change-Id: Ia2345aa262ec791c9f38b6e41e1e4b46f69cadac
OVS agent implementation of l2-population

This patchset implements l2-population RPC callbacks in OVS agents,
it enables plugin to populate forwarding table following portbindings
events.

For now, it doesn't include ARP responder implementation which is
deferred to a future patchset. As this feature isn't supported by OVS
for now. This will require the use of another responder such as ebtables.

It anyway brings some improvements in tunnelling management, as agent
will tear-down unecessary tunnels, and manage flooding on a per-network
basis rather than to all other agents.

These changes should anyway have a limited risk, as tunnel management
won't be affected as long as plugin doesn't implements l2-population.
If this feature is activated on ml2 plugin, it'll stop sending tunnel
endpoints to agents, and use the new RPC callbacks.

Implements: blueprint l2-population

Change-Id: I5185eefedb0ff392bc8b99d16f810813e26ff58d