Introducing Netalloc plugin + E2E tests

[milanlenco]

1. Implemented a new plugin called "Netalloc". It allows to disassociate topology from addressing in the network configuration. The idea is that instead of inserting specific IP/MAC addresses, VXLAN VNIs, etc., into the configuration data for interfaces, routes, ARPs and other network objects, the addresses can be symbolic references into the pool of allocated addresses known to the netalloc plugin.
   The ability to separate addresses from the rest of the network configuration is especially useful in scenarios where address allocations are provided externally, for example by another control-plane agent, IPAM tool or by CNI in containerized environments.
   But for now, only netalloc model for IP addresses has been implemented. To allocate a new IP address, an instance of the proto message IPAllocation should be submitted into the vpp-agent through one of the supported NB transports (etcd, GRPC, ...) under the corresponding key. Network object which references (to-be or already) allocated IP address (e.g interface) will have a dependency on the corresponding key-value instance of IPAllocation and will read and apply the address only once it is available. Possible ways of how to reference IPAllocation from another model are listed here.
   The IP address allocation of netalloc plugin has been already integrated into all of the Linux models and into VPP interfaces. Note that the existing APIs have not been affected - IP addresses were and still are represented in models as strings. But apart from fixed IP addresses, they are now also allowed to symbolically reference addresses from netalloc model instances.
   For example:

        networkName := "example-net" // this is just some logical label

        // allocate IP address for the linux TAP inside a (logical) network "example-net"
        linuxTapAddr := &netalloc.IPAllocation{
		NetworkName: networkName,
		InterfaceName: "example-tap",
		Address: "192.168.10.5/24",
		Gw: "192.168.10.1",
	}

	linuxTap = &linux_interfaces.Interface{
		Name: "example-tap",
		Type: linux_interfaces.Interface_TAP_TO_VPP,
		Enabled: true,
		IpAddresses: []string{
			"alloc:" + networkName,  // take IP address allocated for this interface in the "example-net" network
                        "10.10.5.5/16", // this is a standard fixed IP notation - the address will be added directly as is without dependencies
		},
		Link: &linux_interfaces.Interface_Tap{
			Tap: &linux_interfaces.TapLink{
				VppTapIfName: "vpp-tap"
			},
		},
	}

For more info, see api/models/netalloc/netalloc.proto
There is also a full example under examples/kvscheduler/netalloc
And also included in this PR are end-to-end tests (see 2. below), which also contain netalloc-targeted tests in tests/e2e/020_netalloc_test.go
This plugin, however, is a very fresh idea and very much open for further discussion and suggestions. The first application would be for Contiv-VPP to allocate IP addresses for ligato-based CNFs to attach to (i.e. CNF defines some topology of network items, but Contiv provides addresses that can be used to connect that with the rest of the cluster).
But even in single-agent scenarios this could be useful. By separating addresses from topology the configuration becomes easier to read and a change in addresses will automatically update all related items.

2. Created first few full end-to-end tests written as GO UTs (just like integration tests). See tests/e2e.
   With every UT the VPP and agent are restarted as new processes. I added functions to start/stop microservices (containers with MICROSERVICE_LABEL defined), also added are methods to execute commands inside a microservice, ping IP from VPP or from microservice, check that the agent is in-sync with VPP and Linux, etc.