Support setting priority for every VRRP track interface

[lllyfeng]

Change Scope

• Currently YANG module can only support set one priority for all VRRP tracked interfaces. It's inconvient if one tracked interface wants to have a different priority. So there should be a list for VRRP track interfaces with two numbers, interface and priority-decrement. OLD:

+--rw interface-tracking
    +--rw config
     |  +--rw track-interface* leafref
     |  +--rw priority-decrement? uint8

NEW:

+--rw interface-tracking
    +--rw track-interface* [interface]
        +--rw interface -> ../config/interface
        +--rw config
        |  +--rw interface? leafref
        |  +--rw priority-decrement? uint8
         +--ro state
            +--ro interface? leafref
            +--ro priority-decrement? uint8

• non-backwards compatible.

Platform Implementations

• H3C: https://www.h3c.com/en/Support/Resource_Center/HK/Switches/H3C_S7500E/S7500E/Technical_Documents/Configure___Deploy/Configuration_Guides/S7500E_OM(6300_V1.03)/08-System_Volume/200912/658916_294551_0.htm
• Junos: https://www.juniper.net/documentation/us/en/software/junos/high-availability/topics/ref/statement/track-edit-interfaces-vrrp.html
• Cisco: https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/6-x/unicast/configuration/guide/l3_cli_nxos/l3_vrrp.html search 'track interface'
• Huawei: https://github.com/Huawei/yang/blob/master/network-router/8.22.0/ne40e-x8x16/huawei-vrrp.yang#L1420

[OpenConfigBot]

Major YANG version changes in commit 2e1fe78c3627ab65295636f40324401f04304351: openconfig-if-ip.yang: 3.2.0 -> 4.0.0

[OpenConfigBot]

Compatibility Report for commit 2e1fe78c3627ab65295636f40324401f04304351: ⛔ yanglint@SO 1.10.17

[rolandphung]

Now that I think about it, we are making a breaking change and it might be worth considering adding a possible second action that would shutdown the VRRP instance instead. Perhaps this could be represented as an enum/identity leaf called action and the possible values would be PRIORITY_DECREMENT and DISABLE/SHUTDOWN.

Ref: https://www.arista.com/en/um-eos/eos-varp#xx1153490

[dplore]

Note, does this need to be a breaking change? Since a new container with a different name than the leaf-list is being introduced, the leaf-list could instead be deprecated and the container added. This would make this a non-breaking change and expidite it's merging into the OpenConfig model set.

[dplore]

@lllyfeng waiting for your response on this PR. Thanks

[dplore]

@lllyfeng please address comments if you would like to proceed. I think the only comment that really should be addressed is the one about deprecation vs. making a breaking change. (https://github.com/openconfig/public/pull/829#issuecomment-1663060498)