[dhcp6relay] Apply relay config changes at runtime without container restart

[AnantKishorSharma]

Fixes #18

Why I did it

The SONiC-native DHCPv6 relay agent (dhcp6relay) read the DHCP_RELAY table once at startup and required a dhcp_relay container restart for any subsequent relay configuration change. A container restart is disruptive: it tears down relay state for every VLAN, interrupting DHCPv6 service on all VLANs even when only a single VLAN's configuration changed.

How I did it

Apply DHCP_RELAY changes at runtime instead of requiring a restart:

• A detached monitor thread (config_interface.cpp) subscribes to DHCP_RELAY, VLAN_INTERFACE, VLAN (CONFIG_DB) and INTERFACE_TABLE (STATE_DB), builds the desired per-VLAN config under a mutex, and wakes the libevent main loop through a self-pipe.
• config_change_callback (relay.cpp), on the libevent main thread, reconciles the live vlans map with the desired config: server-list / option changes apply in place, newly-eligible VLANs are armed via the existing link-local-readiness path, and removed VLANs are torn down. All socket and libevent work stays on the main thread; the monitor thread only reads CONFIG_DB and publishes a snapshot under a mutex.
• dhcp6relay now starts unconditionally; the resulting per-packet "config not found" warnings are rate-limited (should_log_throttled).

Dual ToR mode is unchanged — it is still selected by the -u option at startup.

How to verify it

• Unit tests: 59/59 gtests pass — added coverage for the reconcile (apply_desired_config / teardown_vlan_relay / config_change_callback), the config monitor, the STATE_DB interface-readiness path, and the Dual-ToR interface_id default.

• Hardware (qfx5200 t0, sonic-mgmt tests/dhcp_relay/test_dhcpv6_relay_runtime_config.py):

  mode	dhcp6relay command	result
  non-Dual-ToR	/usr/sbin/dhcp6relay	4 passed (304.91s)
  Dual-ToR	/usr/sbin/dhcp6relay -u Loopback0	4 passed (398.09s)

  Each run confirms dhcpv6_servers add/modify/remove and VLAN add/remove apply without a container restart (process PID unchanged) and that the need restart container to take effect log is no longer emitted.

Companion PRs

• sonic-buildimage: [docker-dhcp-relay] Start dhcp6relay unconditionally; apply IPv6 relay config at runtime sonic-buildimage#28042 — start dhcp6relay unconditionally + CLI/templates
• sonic-mgmt: [dhcp_relay] Add dhcp6relay runtime reconfiguration tests sonic-mgmt#25589 — runtime reconfiguration tests
• SONiC (HLD): [doc][dhcp6relay] Add dynamic configuration (no container restart) design SONiC#2402

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[AnantKishorSharma]

@Xichen96 @yaqiangz @jcaiMR @saiarcot895 @yxieca @kellyyeh - Please review when you have a chance.

This makes the SONiC-native dhcp6relay apply DHCP_RELAY configuration changes at runtime, so a dhcp_relay container restart is no longer needed for an IPv6 relay config change. A detached monitor thread watches CONFIG_DB/STATE_DB and the libevent main thread reconciles the live config; Dual ToR (-u) behavior is unchanged.

Companion PRs:

• [docker-dhcp-relay] Start dhcp6relay unconditionally; apply IPv6 relay config at runtime sonic-buildimage#28042 — start dhcp6relay unconditionally + CLI/templates/goldens
• [dhcp_relay] Add dhcp6relay runtime reconfiguration tests sonic-mgmt#25589 — runtime reconfiguration tests
• [doc][dhcp6relay] Add dynamic configuration (no container restart) design SONiC#2402 — HLD

Verification: 59/59 gtests, and on a qfx5200 t0 testbed the new sonic-mgmt tests pass in both modes (non-DualToR 4/4, DualToR -u Loopback0 4/4) — config changes applied at runtime with the process PID unchanged.

[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}

[AnantKishorSharma]

/azpw retry

[mssonicbld]

Retrying failed(or canceled) jobs...

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

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