[active-active] Reassert peer standby after state reset

[dlanov]

Description of PR

Summary:

Reassert the peer Standby forwarding state when the SoC-side state unexpectedly resets to Active while the peer link remains unknown.

Fixes #285

Type of change

• Bug fix
• New feature
• Doc/Design
• Unit test

Approach

What is the motivation for this PR?

When the peer link becomes unknown, linkmgrd switches the peer forwarding state to Standby. If the SoC-side agent later restarts and reports the peer state as Active again, linkmgrd currently accepts that state without reasserting Standby, even though the conditions requiring Standby have not changed.

Work item tracking

• Microsoft ADO (number only):

How did you do it?

After processing a peer mux state notification, check the current state-machine conditions. If the peer reports Active while:

• mux mode is Auto
• the local ToR is Healthy
• the peer link-prober state is PeerUnknown

linkmgrd reasserts the peer Standby state.

The decision is based on the current FSM state rather than mLastSetPeerMuxState, which can contain a stale Standby value after a genuine peer recovery.

How did you verify/test it?

• Full unit-test suite: 191/191 passed
• Added regression coverage for a peer forwarding-state reset from Standby to Active while the peer remains unknown
• Added coverage verifying that a genuine peer recovery to Active does not reassert a stale Standby state
• Existing peer-state regression tests pass
• git diff --check passes

Any platform specific information?

None.

Documentation

No documentation changes required.

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[mssonicbld]

Hi, there are workflow run(s) waiting for approval, you may be first-time contributor. I will notify maintainers to help approve once PR is approved. Thanks!

_{---Powered by SONiC BuildBot}