Implement network name

[toelke]

What this PR does / why we need it:

This allows specifying an optional network_name in the IPAM-config as such:

    {                                                                                                                                                                                                                                          
      "cniVersion": "0.3.1",                                                                                                                                                                                                                   
      "name": "meganet",                                                                                                                                                                                                                       
      "type": "bridge",                                                                                                                                                                                                                        
      "bridge": "meganet",                                                                                                                                                                                                                     
      "ipam": {                                                                                                                                                                                                                                
        "type": "whereabouts",                                                                                                                                                                                                                 
        "range": "10.158.0.1/30",                                                                                                                                                                                                              
        "enable_overlapping_ranges": false,                                                                                                                                                                                                    
        "network_name": "meganet"                                                                                                                                                                                                              
      }                                                                                                                                                                                                                                        
    }                      

This allows re-using the same IP range for multiple L2 networks.

This is achieved by creating the IPPool resource in kubernetes not as 10.158.0.0-30 but as meganet-10.158.0.0.30. When no network-name is given, it defaults to "" and the "-" is left out to enable backwards compatibily.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged): Fixes #50

Special notes for your reviewer (optional): This is only the second time I touch go-code, so if anything seems strange, please do not hesitate to request clarification.

[maiqueb]

I don't think this fixes #50 - that issues clearly mentions namespaced pools. This allows the same range to be spawned across multiple L2 networks, something for which I don't see a clear use case.

Could you elaborate on what use case is this enabling ?

[toelke]

You may be right there -- but the last comment on #50 mentions this idea: https://github.com/k8snetworkplumbingwg/whereabouts/issues/50#issuecomment-874040513

In case you are running multiple L2 networks (by using VLANs, VxLANs, ...) you might want to allow assigning IP addresses to those networks independently. This PR allows to do that.

[toelke]

I marked this as draft until the conclusion of #258 which might require changes to this PR