[config reload] Skip swss readiness check when swss is not present

[william8545]

What I did

config reload (without -f) fails on platforms that do not ship the swss container (e.g. BMC) with swss container is not ready. Retry later or use -f to avoid system checks. The readiness gate waits on a swss.service that does not exist on such images, so reload can never proceed without -f. This makes the gate skip the wait when swss is not present.

How I did it

In _per_namespace_swss_ready(), check the service's systemd LoadState first. If it is not-found (service not built into the image) or masked, return ready — there is no swss to wait for. Platforms that ship swss read LoadState=loaded, so the existing active/120s-settle checks are unchanged. Added unit tests for the not-found/masked paths and regression guards for the loaded/inactive and active/settle behavior.

How to verify it

• pytest tests/config_test.py::TestSwssReady
• On a platform without swss (swss.service is not-found): config reload -y proceeds instead of aborting.
• On a switch that ships swss: behavior is unchanged (still waits until swss has been active for >120s).

Previous command output (if the output of a command-line utility has changed)

root@sonic:~# config reload -y
Acquired lock on /etc/sonic/reload.lock
swss container is not ready. Retry later or use -f to avoid system checks
Released lock on /etc/sonic/reload.lock

New command output (if the output of a command-line utility has changed)

root@sonic:~# config reload -y
Acquired lock on /etc/sonic/reload.lock
Running command: ...   # reload proceeds normally
Released lock on /etc/sonic/reload.lock

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).