ipam: fix inconsistent behavior for same-prefix routes between IPv4 and IPv6

[yushoyamaguchi]

Overview

When multiple routes have the same prefix, IPv4 inserted them as separate entries while IPv6 kernel behavior implicitly merged them into ECMP.
This caused the same config to behave differently depending on the address family.
This patch absorbs the kernel behavior difference on the plugins side to ensure consistent ECMP behavior regardless of address family.

Related issue/PR

#615
#1249

Current behavior

IPv4

When we write as below in cni's json,

      "routes": [
        { "dst": "0.0.0.0/0", "gw": "10.0.0.1" },
        { "dst": "0.0.0.0/0", "gw": "10.0.0.2" }
      ]

Pod's FIB is below

default via 10.0.0.1 dev ens3 
default via 10.0.0.2 dev ens3 

IPv6

When we write as below in cni's json,

  "routes": [
    { "dst": "::/0", "gw": "2001:db8::1" },
    { "dst": "::/0", "gw": "2001:db8::2" }
  ]

Pod's FIB is below

default metric 1024 pref medium
        nexthop via 2001:db8::1 dev ens3 weight 1 
        nexthop via 2001:db8::2 dev ens3 weight 1 

Implementation

Group routes with the same destination prefix, table, scope, and priority, then apply them as a single ECMP route via RouteAddEcmp with MultiPath.

[yushoyamaguchi]

cc @s1061123

[yushoyamaguchi]

This inconsistency has been causing confusion in our operation of production environment, so I am submitting this as a bug fix rather than a feature change.

[s1061123]

/hold

As mentioned in #1249, this code changes IPAM behavior completely and it causes its regression (i.e. this bugfix causes bigger bugs) and current valid configuration is deprecated. In addition, CNI spec does not specify how CNI result object shows ECMP path as well.

It should be held until we conclude its design discussion, in #1249.