m-lag断开peerlink和keepalive恢复后不进入restore状态

m-lag独立运行模式，传统组网

peerlink和keepalive分别断开，模拟两种二次故障后恢复的情况，设备是否会进入restore-delay状态确认功能，目的是为了业务故障后重新恢复，需要保障设备表项全部同步完成后再将业务口开放，以保证转发正常，否则会导致业务异常

restore-delay用来设置设备作为从设备加入M-LAG系统时进行MAC地址表项等信息同步的最大时间。定时器超时之前，业务口(除M-LAG保留接口

和IRF保留接口以外的接口)状态为M-LAG MAD DOWN。定时器超时后，业务口状态变为up。

判断依据：

按照两种二次故障的方式进行验证

人员先将 M-LAG 集群的 Keepalive 链路、Peer-Link 链路同时执行 shutdown 操作，后续直接执行undo shutdown恢复 Peer-Link 链路。

恢复 Peer-Link 链路后，全程未触发 Restore Delay 恢复延时机制，无任何等待周期直接进入业务转发状态，与预设保护机制完全不符。

模拟器测试：

现象1：
1. 先down peer-link、备设备mad down；
2. 后down keepalive、备设备变为standalone、mad解除、角色变为primary；不久后感知到所有m-lag口都是down，角色就变为none、m-lag mad激活
3. undo shut peerlink，备设备角色恢复为secondary，mad状态，进入restore delay；
 
现象2：
1. 先down peer-link、备设备mad down；
2. 后down keepalive、备设备变为standalone、mad解除、角色变为primary；---快速执行第3步
3. undo shut peerlink，备设备角色恢复为secondary，非mad状态，未进入restore delay；

M-LAG Restore Delay 机制的触发核心前提，是备机在恢复 Peer-Link 前处于 None 隔离角色；若备机仍维持 Primary 主用角色，无论 Peer-Link 是否正常恢复，均不会触发该保护机制，与现场故障现象完全一致。而none角色需要一定时间计算，现场瞬间恢复的操作会导致不进入角色状态选举。

现场再尝试等待一段时间后让角色计算进入none状态，再进行恢复，设备成功进入restore-delay的状态