[Nexthop][fboss2-dev] Add fboss2-dev config vlan default CLI command

[vybhav-nexthop]

Pre-submission checklist

• I've ran the linters locally and fixed lint errors related to the files I modified in this PR. You can install the linters by running pip install -r requirements-dev.txt && pre-commit install
• pre-commit run
  Based on upstream PR -> #1091

Why I did it

sw.defaultVlan (thrift: SwitchConfig.defaultVlan) is always
initialized to 4094 in the base agent config and was not previously
configurable via CLI. This command exposes it so operators can redirect
untagged traffic to a different VLAN at bring-up without hand-editing
the JSON config.

How I did it

New command: fboss2-dev config vlan default <vlan-id>, registered
in CmdListConfig.cpp as a sibling of the config vlan <id> subtree
(separate node so the integer arg resolves at the right depth).

Implementation (CmdConfigVlanDefault.cpp): The command implements
the following logic:

1. No-op guard: if sw.defaultVlan already equals the target,
   return immediately with a clear message.
2. Old-default safety check: if the old default VLAN is used as
   ingressVlan for any port but has no matching cfg::Interface entry,
   refuse with a descriptive error (this is the config state that causes
   fboss_sw_agent to crash on startup).
3. Target VLAN lookup: search sw.vlans by ID. If the target VLAN
   already exists, reuse it as-is. If not, auto-create a non-routable
   placeholder: cfg::Vlan{id=vlanId, name="default_<id>", routable=false}.
4. Old VLAN cleanup: if the old default VLAN has no interface and no
   port still uses it as ingressVlan, remove it from the VLAN table.
5. Commit: set sw.defaultVlan\ to the new ID and call
   session.saveConfig().

New files:

• fboss/cli/fboss2/commands/config/vlan/CmdConfigVlanDefault.h/.cpp
  — command implementation
• fboss/cli/fboss2/test/config/CmdConfigVlanDefaultTest.cpp — unit
  tests
• fboss/cli/fboss2/test/integration_test/ConfigVlanDefaultTest.cpp —
  integration tests
• Wired into cmake/CliFboss2.cmake, cmake/CliFboss2TestConfig.cmake,
  cmake/CliFboss2TestIntegrationTest.cmake, fboss/cli/fboss2/BUCK,
  fboss/cli/fboss2/test/config/BUCK,
  fboss/cli/fboss2/test/integration_test/BUCK

Test Plan

Unit tests (CmdConfigVlanDefaultTest) cover the core logic paths:

• setDefaultVlanAlreadySet — no-op when target equals current default
• setDefaultVlanSuccess — happy path: creates new target VLAN, updates
  defaultVlan
• setDefaultVlanUpdatesOnlyOneEntry — no duplicate VLAN entries created
• changeDefaultVlanMultipleTimes — sequential changes accumulate
  correctly
• createsNewVlanWhenNeitherExists — auto-creates target when VLAN table
  lacks it
• reusesExistingTargetVlan — no duplication when target VLAN already
  present
• succeedsWithNoDefaultVlanField — handles Thrift zero-default when
  defaultVlan absent from config

Integration tests (ConfigVlanDefaultTest) run on fboss-sim:

• SetDefaultVlanTo300 — moves eth ports off old default, sets new
  default, commits, verifies sw.defaultVlan via getRunningConfig()
  thrift, restores original state
• NoOpWhenDefaultVlanUnchanged — idempotency: re-setting current
  default returns a clear message with no config change
• RefuseWhenPortOnDefaultVlanWithNoInterface — validation guard:
  refuses change when old default VLAN is used as ingressVlan but has
  no interface (skipped if precondition not met in running config)
• ChangeDefaultVlanWithPortInNonDefaultVlan — regression: command does
  not crash when ports have already been moved off the current default
  VLAN

[meta-cla]

Hi @vybhav-nexthop!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!