Revert "Avoid nhgroup update when mux state changes"

[yxieca]

Reverts #3822

This change is blocking sonic-swss submodule advance for 2 weeks.

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[yxieca]

@manamand2020 Please chime in.

[Copilot]

Pull request overview

This PR reverts PR #3822, restoring nexthop group update operations during mux state changes. The revert is being performed to unblock sonic-swss submodule advancement that has been blocked for 2 weeks.

• Restores nexthop group invalidation and validation calls in MuxNbrHandler::enable()
• Restores nexthop group invalidation and validation calls in MuxNbrHandler::disable()
• Re-adds ECMP nexthop member reference counting during state transitions

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[prsunny]

@Ndancejic, @zjswhhh , dualtor mock tests are failing . Can you check?

[prsunny]

https://elastictest.org/scheduler/publictestplan/6920093d05c827bcee33e11a?testcase=dualtor%2Ftest_orchagent_active_tor_downstream.py&type=console

[manamand2020]

@manamand2020 Please chime in.
https://elastictest.org/scheduler/publictestplan/6920093d05c827bcee33e11a?testcase=dualtor%2Ftest_orchagent_active_tor_downstream.py&type=console

I think this seems to be happening because the neighbor remains in use inside the ECMP group due to the change in the original PR while we try to remove the entry from disableneighbors() which throws this error. We should have some DVS test to cover this. This change is fine though when we do not disable neighbors as part of no-host-route based mux neighbors.

[prsunny]

@manamand2020 Please chime in.
https://elastictest.org/scheduler/publictestplan/6920093d05c827bcee33e11a?testcase=dualtor%2Ftest_orchagent_active_tor_downstream.py&type=console

I think this seems to be happening because the neighbor remains in use inside the ECMP group due to the change in the original PR while we try to remove the entry from disableneighbors() which throws this error. We should have some DVS test to cover this. This change is fine though when we do not disable neighbors as part of no-host-route based mux neighbors.

@manamand2020 , while the change is good with no-host-route, its failing currently on disableneighbors flow. May be we can introduce this as part of no-host-route change. agree?

[manamand2020]

@manamand2020 Please chime in.
https://elastictest.org/scheduler/publictestplan/6920093d05c827bcee33e11a?testcase=dualtor%2Ftest_orchagent_active_tor_downstream.py&type=console

I think this seems to be happening because the neighbor remains in use inside the ECMP group due to the change in the original PR while we try to remove the entry from disableneighbors() which throws this error. We should have some DVS test to cover this. This change is fine though when we do not disable neighbors as part of no-host-route based mux neighbors.

@manamand2020 , while the change is good with no-host-route, its failing currently on disableneighbors flow. May be we can introduce this as part of no-host-route change. agree?

Agreed.