Revert veth name generation due to Calico dependency

[jayanthvn]

*Issue #1159

*Description of changes: In 1.7.0 generateHostVethName was updated in #972 but this isn't compatible with the value expected by calico. Hence calico used to identify the existing ENIs are unexpected routes and delete them.

New format eni name -> enibe59f971f52

192.168.39.120  0.0.0.0         255.255.255.255 UH    0      0        0 enibe59f971f52

Calico generated eni -> eni8478779f379

2020-08-24 21:52:24.310 [INFO][38] int_dataplane.go 1034: Received *proto.WorkloadEndpointUpdate update from calculation graph msg=id:<orchestrator_id:"k8s" workload_id:"default/my-nginx-    86b7cfc89-6lr6v" endpoint_id:"eth0" > endpoint:<state:"active" name:"eni8478779f379" profile_ids:"kns.default" profile_ids:"ksa.default.default" ipv4_nets:"192.168.39.120/32" >

2020-08-24 21:52:25.441 [INFO][38] route_table.go 556: Syncing routes: found unexpected route; ignoring    due to grace period. dest=192.168.48.72/32 ifaceName="enic9f368fa7c4" ipVersion=0x4

2020-08-24 21:52:33.223 [INFO][38] route_table.go 561: Syncing routes: removing old route. dest=192.168.   48.72/32 ifaceName="enic9f368fa7c4" ipVersion=0x4 routeProblems=[]string{"unexpected route"}

Reverting the eni generation, fixed the issue.

192.168.47.127  0.0.0.0         255.255.255.255 UH    0      0        0 enib4f6d4780c5

2020-08-24 22:38:42.227 [INFO][39] int_dataplane.go 1034: Received *proto.WorkloadEndpointUpdate update from calculation graph msg=id:<orchestrator_id:"k8s" workload_id:"default/my-nginx-    86b7cfc89-4hmrr" endpoint_id:"eth0" > endpoint:<state:"active" name:"enib4f6d4780c5" profile_ids:"kns.default" profile_ids:"ksa.default.default" ipv4_nets:"192.168.47.127/32" >

Here is the mapping in calico -

https://github.com/projectcalico/felix/blob/bbb79439123dce009b43d0b99f0b03d651bc142a/fv/workload/workload.go#L96
https://github.com/projectcalico/libcalico-go/blob/677e62cafc19cb9e47aec345c5451bf265c8979f/lib/backend/k8s/conversion/workload_endpoint_default.go#L40

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[mogren]

Thanks @jayanthvn, this was some interesting digging for sure...

[fawadkhaliq]

What's the cost of reverting this? Is there any impact this change have on the VPC CNI? Any consistencies/incompatibility on clusters that have the change #972 (different names) already?

[mogren]

@fawadkhaliq The AWS VPC CNI does not care about the interface name. The reason it was changed in the first place was because we changed the key we use to identify what pod has what IP from just being pod name and namespace to include the container ID as well. (In #972)