[Cherry-pick][Qos]HeadroomPoolSize test with dynamic_threshold based buffer allocation

[ansrajpu-git]

Description of PR

Cheery-picking PR#sonic-net/sonic-mgmt#16885 for msft-202405 branch
Summary:
Fixes # (issue)

Type of change

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

Back port request

• 202012
• 202205
• 202305
• 202311
• 202405

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

[XuChen-MSFT]

@ansrajpu-git paste same comments from sonic-net/sonic-mgmt#16885 to here:
original "HdrmPoolSizeTest" is also support device which is dynamically allocate buffer. and I think dynamic buffer allocation should be default behaviors.
why need add new case ? I just quicky go throught "HdrmPoolSizeTest_withDynamicBufferCacl", I don't found some big difference with original one "HdrmPoolSizeTest" .
The original case is to automatically select the ports and PGs required for the hdrm test in qos_param_generator.py, calculate how much buffer each PG needs to fill the shared buffer according to the dynamic threshold, and then start the consumption test of the headroom pool.

[ansrajpu-git]

@ansrajpu-git paste same comments from sonic-net/sonic-mgmt#16885 to here: original "HdrmPoolSizeTest" is also support device which is dynamically allocate buffer. and I think dynamic buffer allocation should be default behaviors. why need add new case ? I just quicky go throught "HdrmPoolSizeTest_withDynamicBufferCacl", I don't found some big difference with original one "HdrmPoolSizeTest" . The original case is to automatically select the ports and PGs required for the hdrm test in qos_param_generator.py, calculate how much buffer each PG needs to fill the shared buffer according to the dynamic threshold, and then start the consumption test of the headroom pool.

@XuChen-MSFT , The new test has similar test steps to previous test 'HdrmPoolSizeTest' but it was working with multiple check condition for broadcom-dnx platform. With the dynamic buffer allocation, the test was intermittently failing, and we see that there is some adjustment need between the shared pool almost filled and trigger pfc precisely with few more packets.
As suggested by Vineet, we came up with new test specifically to broadcom-dnx platform. We will be raising another PR for removing the broadcom-dnx check from the older test, once this PR is merged.
@vmittal-msft,please comment