PFC_WD|GLOBAL deletion does not reset applied state (BIG_RED_SWITCH stays enabled)

[pinky-nexthop]

Description

Deleting PFC_WD|GLOBAL from CONFIG_DB (or hdel-ing its fields) does not tear down the state that was applied when the key was created. In particular, an active BIG_RED_SWITCH mode stays enabled after the config is removed.

Root cause

PfcWdSwOrch::createEntry applies the GLOBAL fields by value:

• POLL_INTERVAL → updateGroupPollingInterval(...)
• BIG_RED_SWITCH → setBigRedSwitchMode(value), which enables/disables BRS based purely on the string "enable"/"disable".

BRS is therefore only ever disabled by an explicit BIG_RED_SWITCH=disable value. A delete operation carries no value, so nothing calls disableBigRedSwitchMode(): m_bigRedSwitchFlag stays true, the hardware remains in force-drop, and COUNTERS:BIG_RED_SWITCH_MODE stays set.

Steps to reproduce

1. redis-cli -n 4 HSET "PFC_WD|GLOBAL" BIG_RED_SWITCH enable → BRS engages, monitored queues force-dropped.
2. redis-cli -n 4 DEL "PFC_WD|GLOBAL" (or HDEL the last field).
3. Observe BRS is still active (COUNTERS:BIG_RED_SWITCH_MODE still enable, queues still force-dropped).

Expected behavior

Consistent with SONiC's config model, removing PFC_WD|GLOBAL (or its fields) should reset the GLOBAL-derived state to defaults — i.e. disable BRS mode and restore the default poll interval — rather than leaving the last-applied state in effect.

Notes

• This is a pre-existing behavioral gap, independent of the null-deref crash fixed in [pfcwdorch]: Fix null-deref crash when non-port GLOBAL key is deleted #4760. That PR intentionally makes GLOBAL deletion a safe no-op for the per-port teardown path; the state-reset behavior is deferred here as a follow-up.
• Fixing this would involve, on GLOBAL delete, calling disableBigRedSwitchMode() and resetting the poll interval to its default, plus a DVS test asserting BRS actually clears after deletion.