Clean up procedure for ptf based

[SkayKvit]

To minimize overhead for successful tests, the system implements a dedicated recovery mechanism that activates only after a test failure or class change. This prevents heavy NPU cleanup operations when the hardware state is valid, while resolving previous issues caused by misconfigured scope="class" fixtures, which frequently left "dirty" states for subsequent test runs.
The system relies on the following key components:

1. **TopologyManager**: Manages the topology lifecycle and mocks critical npu methods with safe stubs, preventing framework crashes during hardware errors.
   

2. **safe_execute**: Intercepts exceptions during NPU interactions, returning null objects instead of crashing the RPC queue.
   

3. **verify_sai_clean_state**: Serves as a diagnostic helper that inspects the NPU's internal tables (such as FDB or VLAN members) to confirm the hardware is truly empty, acting as a final safeguard before proceeding with a new test suite.
   

4. **sai_ptf_topology_manager**: A class-scoped fixture that caches the topology for all tests within a class, optimizing execution speed.
   

5. **sai_ptf_topology**: A function-scoped fixture that performs "smart" recovery: it resets the NPU and flushes Redis queues only when a failure is detected or a class mismatch occurs, correcting issues with improper scope contexts.
   

6. **setup_teardown**: Automates hardware configuration, synchronizing the NPU state before every test and ensuring a predictable, clean environment.
   

[zikkend]

this fixture shouldn't be in conftest.py because it is only applicable for testbeds with npu. Testbed can have phy or dpu instead

[illia-smulskyi]

do we need this?

[zikkend]

For npu it doesn't matter which sai client it uses: Redis or Thrift. It can't use data directly from Redis db like "ASIC_STATE:SAI_OBJECT_TYPE_FDB_ENTRY*" here

[zikkend]

We can't simply mock the npu create or remove methods because if they fail, there is usually a legitimate reason. It's typically either a bug in the SAI-Challenger itself during topology creation, the test case setup/teardown, or the SAI implementation