Force bonds/vlans re-parsing when lower layer changes

[milan-zededa]

Description

parseBonds and parseVlans each use a content hash to skip parsing when their own config is unchanged. However, both store pointers to lower-layer objects (physio pointers in bond.lowerPhysPorts, bond pointers in vlan.lowerL2Ports) obtained at parse time. If a lower layer is parsed without the dependent layer being parsed, those pointers become stale (pointing at parsed old config).

Fix by propagating force-parse down the dependency chain:

• parseBonds is forced to parse when physio changes
• parseVlans is forced to parse when physio or bonds change

How to test and validate this PR

Set up a device with four network adapters (e.g. eth0–eth3) and configure two bonds with VLAN sub-interfaces on top:

Initial config

• bond1: aggregates eth0, eth1 — management uplink (DHCP)
• bond2: aggregates eth2, eth3
• vlan20, vlan21: parent port bond2

Apply this config and confirm the device connects and reports no port errors.

Config change — swap eth1 and eth2 between the bonds

• bond1: aggregates eth0, eth2
• bond2: aggregates eth1, eth3
• VLANs unchanged

Expected (correct) result
/run/zedagent/DevicePortConfig/zedagent.json should show:

• bond1.Bond.AggregatedPorts = ["eth0", "eth2"]
• bond2.Bond.AggregatedPorts = ["eth1", "eth3"]
• No LastError on any port

Regression (what the bug produced)
Without the fix, parsed VLAN config would remain stale from a prior parse and zedagent.json could show eth2 under both bond1 and bond2, resulting in:

LastError: "Port eth2 is aggregated by multiple bond interfaces (bond1, bond2, ...)"

Changelog notes

Fixed a bug where re-configuring bond membership (e.g. swapping physical interfaces between two bonds) could leave the device with a broken network configuration and a port aggregated by multiple bonds error, requiring a reboot to recover.

PR Backports

• 16.0-stable: To be backported.
• 14.5-stable: To be backported.
• 13.4-stable: To be backported.

Checklist

• I've provided a proper description
• I've added the proper documentation
• I've tested my PR on amd64 device
• I've tested my PR on arm64 device
• I've written the test verification instructions
• I've set the proper labels to this PR
• I've checked the boxes above, or I've provided a good reason why I didn't check them.

[eriknordmark]

Run tests. Some yetus issues to fix.

[milan-zededa]

Run tests. Some yetus issues to fix.

Those yetus issues shown are for unchanged lines. In fact, the Yetus check is green, so this is some github/yetus/workflow fail.

[codecov]

Codecov Report

❌ Patch coverage is 66.66667% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 22.07%. Comparing base (63fa63d) to head (f557b5d).
⚠️ Report is 6 commits behind head on master.

Files with missing lines	Patch %	Lines
pkg/pillar/cmd/zedagent/parseconfig.go	66.66%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #5902      +/-   ##
==========================================
+ Coverage   21.62%   22.07%   +0.44%     
==========================================
  Files         464      474      +10     
  Lines       83994    85692    +1698     
==========================================
+ Hits        18166    18914     +748     
- Misses      64300    65073     +773     
- Partials     1528     1705     +177     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[rene]

Run tests. Some yetus issues to fix.

Those yetus issues shown are for unchanged lines. In fact, the Yetus check is green, so this is some github/yetus/workflow fail.

If you look to the logs, Yetus is passing100%, I think is checking correctly only the patch. You see the other errors because they were propagated from the annotation step. The annotation step will not fail (on purpose), I based the final result exclusively from Yetus, but we can change that....

In any case, @milan-zededa , it makes sense to take this opportunity and fix these Yetus errors in the files you changed and make them truly 100% pass...

[milan-zededa]

Rebased on the top of the latest master. I do not really want to include unrelated changes to this PR just to please Yetus.

[eriknordmark]

LGTM