Just experimenting....

I couldn't help but code something...  I've been experimenting with different incarnations of the extension interfaces.  I created this pull request just so you could see what I'm up to.  The main diff is https://github.com/ibuildthecloud/docker/commit/146ddf90d8de8107f22db41354d7d32e8563e9e5  Obviously don't merge this.  I realize much of this will be throw away.  Here's some of the ideas I've been playing with

## Network Provider

I've created the concept of a Network Provider.  So far there are three extension interfaces we've talked about: Ports, Network, and DNS/Naming.  These extensions are loosely related.  A Network Provider provides a means to compose these extensions into one working set.  Every Port extension will not work with every Network extension for example.  It is far too difficult to ensure such a thing.  But many Port extensions will be compatible with many other Network extensions.  The Network Provider allows you to group specific extensions together into a validated set.

Additionally, the network provider can be used to assist in creating a network.  When you create a network you could say `docker network create --provider=xyz`.  This allows the user to say that they want a network implemented by system X, but not necessarily have to say "vlan."

## Remove Required Core State

Most of the code I've seen so far has some global map of all Networks and Endpoints.  This basically implies we will have one core state in Docker that has all network information in it.  This approach can either be a great help or a hindrance depending on your networking system.

For many drivers it will be very convenient to have the State object that is magically synced across the cluster.  From some SDN systems, the SDN system already has a global view of all hosts, networks, and containers.  Requiring the core state be in Docker means that the SDN will need to always synchronize state between the two.

What I've done in this PR is move the management of the state to the Network Provider.  When the Network Provider is initialized it is passed a State object which it is free to use at it will.  Core docker does not maintain a list of networks/endpoints but instead iterates over the Providers and calls ListNetworks() or GetNetwork(id).  This small change makes it such that there is no required one core state in Docker.  State can be distributed across providers in provider specific fashions such that three providers installed can synchronize state in three different ways if they're so inclined.

## More Endpoint LifeCycle methods

Add and remove endpoint is not really sufficient.  There needs to be add, remove, activate, deactivate.  This essentially maps to container create, start, stop, remove.  The networking system needs to be aware of all these life cycle events.  On create the networking system should reserve resources.  For example if you are doing L2 virtualization, you'd probably reserve a MAC address at this time.  On start the network system should make connectivity possible.  On stop the network system should attempt to gracefully remove connectivity (a PreDeactivate could be needed too so you can do things like gracefully remove a container from a load balancer).  On remove the networking system should release any resources reserved to the container.

## Find incremental approaches

I wanted to walk through all the changes needed to see if there are ways we can implement this without boiling the ocean.  I believe there are some simple ways we can roll out this functionality without requiring huge refactoring of libcontainer, persistent netns, a distribute state implementation, vxlan, etc.  I can share my thoughts at a later time.