crm_stats_ipv6_route_available counter was not decremented

[anshuldubela]

Description of PR

issue

     if check_available_counters and not (crm_stats_route_available - new_crm_stats_route_available >= 1):
         for i in range(total_routes):
             RESTORE_CMDS["test_crm_route"].append(route_del_cmd.format(asichost.ip_cmd, i, nh_ip))

> pytest.fail(""crm_stats_ipv{}_route_available" counter was not decremented".format(ip_ver))
E Failed: "crm_stats_ipv6_route_available" counter was not decremented

Summary:
Fixes # (issue)
As per the detailed UT with crm/test_crm.py::test_crm_route, below are my observations:

• While CRM_POLLING_INTERVAL we can opt for CRM_UPDATE_TIME = 5 as FDB table get repopulated post 5msec which tends to fail our test checks.
• While initial stage of testcase post route add extra 10msec to gather exact stats.
• As for Cisco-8000 devices, hardware counters are statistical-based with +/- 1 entry tolerance. Hence, the available counter may not increase as per initial value.
  crm_stats_route_available - new_crm_stats_route_available > 1

Type of change

• Bug fix
• Testbed and Framework(new/improvement)
• Test case(new/improvement)

Back port request

• 201911
• 202012
• 202205
• 202305
• 202311

Approach

What is the motivation for this PR?

How did you do it?

How did you verify/test it?

Any platform specific information?

Supported testbed topology if it's a new test case?

Documentation

[kevinskwang]

@anshuldubela could you fix the conflict?

[anshuldubela]

@kevinskwang Please review.

[mssonicbld]

Cherry-pick PR to 202405: #14104