Backport the network recipies from Crowbar 2.0 [3/3]

This backports the network barclamp recipies from Crowbar 2.0 into Pebbles.

From the original commit:

Rewrite network barclamp to manage interfaces directly.

    Making the distro tools handle reconfiguring network interfaces for us
    was needlessly fragile, since we were rewriting the network config and
    changing the state of the interfaces while we were in the middle of
    converging the node -- if we happened to do anything that would try to
    talk to the chef-server while any of the interfaces needed to talk to
    the admin network was changing, we could easily wind up in a state
    where manual intervention would be needed to recover.

    Additionally, the network barclamp had to have a good deal of
    special-casing to handle all the distro-specific caveats that went
    along with using ifup/ifdown directly to manage the nics.

    This code does away with all that by teaching the network barclamp how
    to manage our interfaces directly, reducing the distro-specific code
    to what is needed to write out the proper configuation for ifup/ifdown
    on the operating system.

    New features:

     * All interface manipulation happens early in the compile phase of
       the chef-client runs, and the recipe will pause for up to 60
       seconds to verify that it can ping the node with the provisioner
       role (if one is assigned).  This should ensure that the chef-client
       run succeeds with minimal delay even when we are forced to do
       something that may trigger a spanning tree update on the
       network. This frees the rest of the barclamps from having to care
       about sleeping due to network configuration changes.
     * The network barclamp posts its state on
       node[:crowbar_wall][:network] to allow other barclamps to easily
       see what interfaces are members of what network and what IP
       addresses are assigned to the node.
     * Switching between single, dual, and team mode is more or less
       seamless now. You can easily switch network modes even when nova VMs are
       up and running without dropping more than a packet or two. The sole
       exception I have seen is Nova running in tenant_vlan mode.
     * It is trivial to deploy with a configuration that does not use vlan
       tagging at all.  The network barclamp will manage our interfaces
       correctly by assigning multiple IP addresses to the appropriate
       interfaces for each network, and it will handle moving addresses
       and routes around as needed.  Debian and Redhat config file
       generation has been updated to handle binding multiple IP addresses
       to interfaces so that a rebooted node will come up with the proper
       configuration before chef-client runs.
     * Helper classes have been added to the barclamp recipe that model IP
       addresses (including IP address ranges) and network interfaces.
       Those helpers also inject convienenece routines into the CHef::Node
       class to make it easier to find interfaces and addresses for each
       of our networks.

 chef/cookbooks/network/metadata.rb                 |    6 +
 chef/cookbooks/network/recipes/default.rb          |  784 ++++++++------------
 chef/cookbooks/network/recipes/switch_config.rb    |    2 +-
 .../network/templates/default/interfaces.erb       |   76 +-
 .../network/templates/default/redhat-cfg.erb       |   73 +-
 .../network/templates/default/suse-cfg.erb         |   40 +
 .../network/templates/default/suse-route.erb       |    3 +
 7 files changed, 425 insertions(+), 559 deletions(-)

Crowbar-Pull-ID: 57b4821d276e5da97e9a031ecb6ab6c94f74ce80

Crowbar-Release: pebbles