[test gap][dualtor-as] dualtor linked with ycable should recover from inconsistency when cable firmware is corrupted

[zjswhhh]

Description It's noticed that in production cable can go bad and give false values on the EEPROM, but data plane stays alive.

If mux toggles happen, ToRs can end up as both side active, and unable to recover. The issue should be fixed by https://github.com/sonic-net/sonic-linkmgrd/pull/184/files.

But there is a test gap here.

Steps to reproduce the issue:

• Case 1

  1. make ycable only writes unknown to DB for mux probing
  2. Trigger a mux toggle to active on standby side
  3. monitor both ToR's local mux state, it should be consistent eventually

• Case 2:

  1. make ycable only writes PeerLinkState==Down to DB (while peer's link state is indeed healthy)
  2. Trigger a mux toggle to active on standby side
  3. monitor both ToR's local mux state, it should be consistent eventually

Describe the results you received:

Describe the results you expected:

Additional information you deem important:

**Output of `show version`:**

```
(paste your output here)
```

**Attach debug file `sudo generate_dump`:**

```
(paste your output here)
```

[StormLiangMS]

hi @prgeor this one seems a platform related test gap, assigned to you for further triage.

[vdahiya12]

1. to simulate Case 1, we can see if stopping ycabled/mux_sumulator combination can lead to achieve the case. we can add the test case in DualToR test cases if this test is not.
2. for case 2 we can add fixture to mux-simulator to return link down for sometime and that should achieve the desired sceenario. During teardown we can restore the link state .

[zjswhhh]

Hi @StormLiangMS - I think it's okay to lower the priority of this item. The gap is a very specific scenario, image fix has checked in long time ago, the issue is not impacting production. Can you help put the right label on?

[StormLiangMS]

hi @yxieca @zjswhhh Prince told me this would be owned by you, changed the owner and set to P1.