[ZTP] Re-assert front panel port config after ZTP profile removal (202311.X)

[gord1306]

Cherry-pick of #6 onto 202311.X, so that the mainline branch carries the same fix as 202311.X_4630_10g_prod. The resulting ztp-profile.sh is byte-identical to the one on the product branch.

Why

ztp-profile.sh remove deletes ZTP|mode from CONFIG_DB and then restarts interfaces-config, which regenerates /etc/network/interfaces from interfaces.j2. The ZTP in-band block of that template is gated on ZTP['mode'], so once the table is gone the regenerated file contains no Ethernet stanza at all.

interfaces-config.sh then runs systemctl restart networking, which performs ifdown -a followed by ifup -a. ifupdown2 tears down every front panel port it had adopted for ZTP in-band DHCP, and ifup -a does not bring them back because they are no longer listed. The netdev is left administratively down with its MTU reset to the kernel default, while CONFIG_DB, APPL_DB and the ASIC all still report the port as up.

Because show interfaces status reads APPL_DB, the CLI shows up/up and the problem is invisible from there, while anything running on the netdev - LLDP and DHCP in particular - silently stops working. Recovery requires a manual config interface shutdown/startup on each affected port.

Nothing corrects this afterwards: portmgrd only acts on CONFIG_DB events and keeps no desired state. It erases each event once applied, and its periodic tick returns immediately when the queue is empty. Since CONFIG_DB never changed, portmgrd receives no event and the drift persists.

Which ports are affected depends only on which ones happened to be oper up when interfaces-config sampled APPL_DB, so the failure looks intermittent. If several ports come up close together they are all adopted and all end up down.

What this does

After the interfaces-config restart in the remove path, re-assert the front panel port configuration. Writing any field of CONFIG_DB PORT|<port> back with its current value produces a keyspace event, and SubscriberStateTable delivers the entire hash to the consumer, so portmgrd re-applies both mtu and admin_status even though only admin_status is written.

Possible concerns

• Link flap. None. The write does not change CONFIG_DB content, and portmgrd applying admin_status up to a port that is already up is a no-op at the netdev level. Verified on hardware: ip -o link show is byte-identical before and after, and the HSET returns 0 (no field added).
• Ordering. interfaces-config.service and networking.service are both Type=oneshot, and neither restart above uses --no-block, so ifdown/ifup have completed by the time the loop runs.
• Ports intentionally left down. The current value is written back, so a port configured admin_status down stays down.
• Runtime. Two sonic-db-cli calls per port. Measured at 1.8 s for 54 ports on an AS4630-54PE, inside a teardown path that already restarts two services.

Verification

Validated on an AS4630-54PE running in-band ZTP with an official build. After ZTP removes its profile the teardown is confirmed to have happened - /etc/network/interfaces holds no Ethernet stanza and ZTP|mode is cleared - and all 48 cabled front panel ports stay up with MTU 9100. lldpd keeps transmitting and the peer captures LLDP frames at the expected 30 second interval.

Without the fix, the same environment leaves all 48 ports netdev DOWN with MTU 1500 while show interfaces status reports every one of them as up/up, and no LLDP frames are transmitted at all.