Return success from CNI DEL when IPAMD is unreachable

[jdn5126]

What type of PR is this?
bug

Which issue does this PR fix:
#2331

What does this PR do / Why do we need it:
This PR modifies the VPC CNI pod deletion logic to return no error to the container-runtime when IPAMD is unreachable. This is needed for three primary reasons:

1. The CNI spec specifies that delete operations should generally complete without error, even when resources are missing.
2. The CNI cannot count on kubelet to retry deletes until IPAMD is available. If a user deletes a pod with a termination grace period of 0 seconds, the pod is deleted from the API server before kubelet returns success, so kubelet will give up after a few iterations.
3. If the aws-node daemonset pod cannot be scheduled until other pods are deleted, pod deletion needs to happen without IPAMD.

CNI Changes:
As before, the CNI will try to delete non-branch-ENI pods using PrevResult when IPAMD is not reachable. The difference is that CNI will now return no error in this case. Note that PrevResult will only be available for pods created with VPC CNI v1.12.1+. For pods created before this, IP rules will be leaked, and it is IPAMD's responsibility to cleanup these rules when it starts again.

IPAMD Changes:
On init, IPAMD identifies stale allocations and prunes IP rules for these stale allocations. IPAMD cannot be sure if CNI was able to prune those rules before the pod was deleted. Also, IPAMD does an additional state file write after pruning entries.

Misc:
I also did some refactoring of network utilities to avoid code duplication.

If an issue # is not available please add repro steps and logs from IPAMD/CNI showing the issue:
N/A

Testing done on this change:
Added unit test coverage for stale IPAM allocations. Manually created a cluster and verified behavior when IPAMD is unreachable, plus upgrade/downgrade scenarios.

Automation added to e2e:
N/A

Will this PR introduce any new dependencies?:
N/A

Will this break upgrades or downgrades. Has updating a running cluster been tested?:
No, Yes

Does this change require updates to the CNI daemonset config files to work?:
No

Does this PR introduce any user-facing change?:
Yes

Update CNI to delete pod when IPAMD is unreachable.

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

[jayanthvn]

If we cleanup resources and then call IPAMD then this check wouldn't be needed..

[jdn5126]

Right, but we can only do that if the pod was created by v1.12.1+. It would be great to remove this overhead in the future, but in the common case, there should never be any stale allocations to clean up

[M00nF1sh]

/approve
approving given we'll do the mentioned refactor as follow up.