[Nexthop][fboss2-dev] Add config/delete copp cpu-traffic-policy match action CLI

[vybhav-nexthop]

Summary

Adds a config/delete command pair for CPU-plane action fields in
sw.cpuTrafficPolicy.trafficPolicy.matchToAction:

fboss2-dev config copp cpu-traffic-policy match <matcher-name> action <action-type> <value>
fboss2-dev delete copp cpu-traffic-policy match <matcher-name> action <action-type>

Supported action types: send-to-queue <queue-id>, counter <name>, set-tc <tc-value>, user-defined-trap <queue-id>.

Each action type sets one field of cfg::MatchAction and applies to the packets the referenced ACL matches that are punted to the CPU:

• send-to-queue <queue-id> — steer the matched CPU-bound packets to a specific CPU queue. CPU queues are individually rate-limited/prioritized, so this is meant for isolating control traffic (e.g. BGP) from best-effort punts. (QueueMatchAction.queueId)
• counter <name> — attach a named packet/byte counter to the matched traffic. Observability only; no forwarding effect. (MatchAction.counter)
• set-tc <tc-value> — set the internal traffic class on the matched packets; the ASIC's TC→queue map then resolves the destination CPU queue. Today this shares the same hardware primitive as send-to-queue (the queue-id is programmed as the TC value in SaiAclTableManager). tcValue is a thrift byte, so the accepted range is [0, 127]. (SetTcAction.tcValue)
• user-defined-trap <queue-id> — bind the match to a dedicated SAI hostif user-defined trap on the given CPU queue, so the ACL rule takes precedence over the default hostif trap rules. Platform-gated on SAI_USER_DEFINED_TRAP. (UserDefinedTrapAction.queueId)

Both are applied at HITLESS level: matchToAction is processed through the ACL update path in ApplyThriftConfig.cpp, and no ChangeProhibited guards exist for these fields.

Test Plan

Unit tests

//fboss/cli/fboss2/test/config:cmd_config_test — full suite passes, including:

• 8 new cpuTrafficPolicy* tests in CmdConfigCoppTest.cpp: arg validation (arity, literal tokens, action types, value ranges) and queryClient behavior (add to existing matcher preserving other action fields, create new matcher entry, overwrite same action type, user-defined-trap).
• 8 delete tests in CmdDeleteCoppCpuTrafficPolicyMatchActionTest.cpp: arg validation plus delete of each action type, absent-field and absent-matcher handling.

Integration test

ConfigCoppCpuTrafficPolicyTest.addAndDeleteAction on an NH-4010-F device exercises the full cycle: picks an ACL from the running config as matcher (one without a pre-existing action of the tested type); if the config has no usable ACL — the default on freshly bootstrapped devices (empty AclTable1) and the simulator — it injects a test-owned ACL (fboss2-copp-test-acl) through the config session and uses that. Then add → commit → verify present → delete → commit → verify gone.

Cleanup is snapshot-based: SetUp captures the running config before any mutation, and TearDown writes it back through the session (hitless commit) only if the committed config drifted — so the test restores the switch on pass or fail, on both the pre-existing-matcher and injected-ACL paths.

Post-run checks: no fboss2-copp-test-acl leftovers in the committed agent config, fboss_sw_agent NRestarts=0 across all commits.

Review Findings

A multi-angle pre-publication review (8 finder passes + adversarial verification) ran on this diff. Two confirmed issues were fixed in this PR:

• Matcher name action collision: the delete command models the grammar as subcommand tree nodes, so CLI11 classifies a bare action token as the subcommand before filling the matcher-name positional — a matcher literally named action would be configurable but undeletable. The config command now rejects that name up front (with a unit test).
• Empty-entry pruning on the already-absent path: deleting an action field that was already absent returned early before the empty-MatchAction prune, so a pre-existing entry with no action fields (hand-edited config) survived. The prune now runs regardless, and the entry is removed (with a unit test).

Remaining low-severity notes, documented for reviewer awareness: the four action-type dispatch chains (validate/apply/delete/isValid) are maintained separately and each ends in a bare else for user-defined-trap; the integration test's injected ACL uses a dstIp qualifier that could be rejected on a hypothetical ACL table configured with a restricted qualifier set (current platforms use the full-set fallback).