…run on chassis (sonic-net#2985)

What is the motivation for this PR?
Add new test cases for api for test plan introduced by PR sonic-net#2695 sonic-net#2695 (refer to sections 2 to 6)
Need to run existing api tests against a Sonice chassis but all of the tests were using duthost and hence will always run one of duthost of chassis i.e supervisor or line card. Converted these tests to use the enum_* fixture per hwsku for dut selection. Instead of running gather facts as fixture get facts within compare function for selected duthost.

How did you do it?
Following changes made to api helper files in folder sonic-mgmt/tests/common/helpers/platform_api/
chassis.py:
add new api calls: get_module_index, get_supervisor_slot, get_my_slot, is_modular_chassis

fan_drawer.py:
add new api call: get_maximum_consumed_power

module.py:
add new api calls: get_description,	get_slot, get_type,	get_oper_status, get_midplane_ip, 
is_midplane_reachable, get_maximum_consumed_power, reboot, set_admin_state

psu.py:
add new api calls: get_maximum_supplied_power, set_status_master_led, get_status_master_led

thermal.py:
add new api calls: get_minimum_recorded, get_maximum_recorded
changes maded to api tests to support Sonic Chassis and add tests for new apis:

conftest.py:
changes to run tests on  Sonic chassis
change  plaftorm_api_conn to support multidut by using duthosts and enum_rand_one_per_hwsku_hostname to select dut at function level, 
change from getting ip from eth0 to duthost.mgp_ip to extract ip address for DUT 

change start_platform_service  to support multidut by using duthosts and enum_rand_one_per_hwsku_hostname to select dut at function level,
change from getting ip from eth0 to duthost.mgp_ip to extract ip address for DUT 

change in stop_platform_api_service: to support on all duts where the service was started
for all test modules under api these are common changes :
Remove gather_facts fixture and get facts within compare_value_with_platform_facts per duthost from test
changes changes to run tests on Sonic chassis, Replace duthost with duthosts and enum_rand_one_per_hwsku_hostname for multidut environment for all tests

other changes per module:

test_chassis.py:
add tests for new apis for chassis: get_module_index, get_supervisor_slot, get_my_slot, is_modular_chassis

test_component.py:
remove range since image_list is list for image in range(image_list) 

test_fan_drawer.py:
add test for new apis for fan_drawer: get_maximum_consumed_power

test_module.py
add tests for new apis for module_base: get_description,	get_slot, get_type,	get_oper_status, get_midplane_ip, 
is_midplane_reachable, get_maximum_consumed_power, reboot, set_admin_state

test_psu.py
changes changes to run tests on  Sonic chassis,
add tests for new apis: get_maximum_supplied_power, set_status_master_led, get_status_master_led

test_thermal.py
changes changes to run tests on  Sonic chassis, 
add tests for new apis for thermal: get_minimum_recorded, get_maximum_recorded

How did you verify/test it?
Validated the modified tests against chassis.

…run on chassis (sonic-net#2985)

What is the motivation for this PR?
Add new test cases for api for test plan introduced by PR sonic-net#2695 sonic-net#2695 (refer to sections 2 to 6)
Need to run existing api tests against a Sonice chassis but all of the tests were using duthost and hence will always run one of duthost of chassis i.e supervisor or line card. Converted these tests to use the enum_* fixture per hwsku for dut selection. Instead of running gather facts as fixture get facts within compare function for selected duthost.

How did you do it?
Following changes made to api helper files in folder sonic-mgmt/tests/common/helpers/platform_api/
chassis.py:
add new api calls: get_module_index, get_supervisor_slot, get_my_slot, is_modular_chassis

fan_drawer.py:
add new api call: get_maximum_consumed_power

module.py:
add new api calls: get_description,	get_slot, get_type,	get_oper_status, get_midplane_ip, 
is_midplane_reachable, get_maximum_consumed_power, reboot, set_admin_state

psu.py:
add new api calls: get_maximum_supplied_power, set_status_master_led, get_status_master_led

thermal.py:
add new api calls: get_minimum_recorded, get_maximum_recorded
changes maded to api tests to support Sonic Chassis and add tests for new apis:

conftest.py:
changes to run tests on  Sonic chassis
change  plaftorm_api_conn to support multidut by using duthosts and enum_rand_one_per_hwsku_hostname to select dut at function level, 
change from getting ip from eth0 to duthost.mgp_ip to extract ip address for DUT 

change start_platform_service  to support multidut by using duthosts and enum_rand_one_per_hwsku_hostname to select dut at function level,
change from getting ip from eth0 to duthost.mgp_ip to extract ip address for DUT 

change in stop_platform_api_service: to support on all duts where the service was started
for all test modules under api these are common changes :
Remove gather_facts fixture and get facts within compare_value_with_platform_facts per duthost from test
changes changes to run tests on Sonic chassis, Replace duthost with duthosts and enum_rand_one_per_hwsku_hostname for multidut environment for all tests

other changes per module:

test_chassis.py:
add tests for new apis for chassis: get_module_index, get_supervisor_slot, get_my_slot, is_modular_chassis

test_component.py:
remove range since image_list is list for image in range(image_list) 

test_fan_drawer.py:
add test for new apis for fan_drawer: get_maximum_consumed_power

test_module.py
add tests for new apis for module_base: get_description,	get_slot, get_type,	get_oper_status, get_midplane_ip, 
is_midplane_reachable, get_maximum_consumed_power, reboot, set_admin_state

test_psu.py
changes changes to run tests on  Sonic chassis,
add tests for new apis: get_maximum_supplied_power, set_status_master_led, get_status_master_led

test_thermal.py
changes changes to run tests on  Sonic chassis, 
add tests for new apis for thermal: get_minimum_recorded, get_maximum_recorded

How did you verify/test it?
Validated the modified tests against chassis.

…run on chassis (sonic-net#2985)

What is the motivation for this PR?
Add new test cases for api for test plan introduced by PR sonic-net#2695 sonic-net#2695 (refer to sections 2 to 6)
Need to run existing api tests against a Sonice chassis but all of the tests were using duthost and hence will always run one of duthost of chassis i.e supervisor or line card. Converted these tests to use the enum_* fixture per hwsku for dut selection. Instead of running gather facts as fixture get facts within compare function for selected duthost.

How did you do it?
Following changes made to api helper files in folder sonic-mgmt/tests/common/helpers/platform_api/
chassis.py:
add new api calls: get_module_index, get_supervisor_slot, get_my_slot, is_modular_chassis

fan_drawer.py:
add new api call: get_maximum_consumed_power

module.py:
add new api calls: get_description,	get_slot, get_type,	get_oper_status, get_midplane_ip, 
is_midplane_reachable, get_maximum_consumed_power, reboot, set_admin_state

psu.py:
add new api calls: get_maximum_supplied_power, set_status_master_led, get_status_master_led

thermal.py:
add new api calls: get_minimum_recorded, get_maximum_recorded
changes maded to api tests to support Sonic Chassis and add tests for new apis:

conftest.py:
changes to run tests on  Sonic chassis
change  plaftorm_api_conn to support multidut by using duthosts and enum_rand_one_per_hwsku_hostname to select dut at function level, 
change from getting ip from eth0 to duthost.mgp_ip to extract ip address for DUT 

change start_platform_service  to support multidut by using duthosts and enum_rand_one_per_hwsku_hostname to select dut at function level,
change from getting ip from eth0 to duthost.mgp_ip to extract ip address for DUT 

change in stop_platform_api_service: to support on all duts where the service was started
for all test modules under api these are common changes :
Remove gather_facts fixture and get facts within compare_value_with_platform_facts per duthost from test
changes changes to run tests on Sonic chassis, Replace duthost with duthosts and enum_rand_one_per_hwsku_hostname for multidut environment for all tests

other changes per module:

test_chassis.py:
add tests for new apis for chassis: get_module_index, get_supervisor_slot, get_my_slot, is_modular_chassis

test_component.py:
remove range since image_list is list for image in range(image_list) 

test_fan_drawer.py:
add test for new apis for fan_drawer: get_maximum_consumed_power

test_module.py
add tests for new apis for module_base: get_description,	get_slot, get_type,	get_oper_status, get_midplane_ip, 
is_midplane_reachable, get_maximum_consumed_power, reboot, set_admin_state

test_psu.py
changes changes to run tests on  Sonic chassis,
add tests for new apis: get_maximum_supplied_power, set_status_master_led, get_status_master_led

test_thermal.py
changes changes to run tests on  Sonic chassis, 
add tests for new apis for thermal: get_minimum_recorded, get_maximum_recorded

How did you verify/test it?
Validated the modified tests against chassis.

in test_get_presence() there is a new check added by PR (#2985):

                    name = module.get_name(platform_api_conn, i)
                    if name in self.skip_mod_list:
                        self.expect(presence is False, "Module {} is not present".format(i))
                    else:
                        self.expect(presence is True, "Module {} is not present".format(i))

I am seeing some issue with the above logic.
In our testbed where we share a physical chassis that uses the same Supervisor card but group different LCs for different "logical chassis" so for some "logical chassis" some LCs are added to "skip_mod_list" as they are not meant to be tested for that logical chassis.  Our expectation is that if it is marked as skipped, it is not meant for testing and no state of those skipped modules should be used for any validation logic.   We should always trust what the inventory marked as skipped and not try to look at whatever state the "skipped module" should be.

in test_get_presence() there is a new check added by PR (sonic-net#2985):

                    name = module.get_name(platform_api_conn, i)
                    if name in self.skip_mod_list:
                        self.expect(presence is False, "Module {} is not present".format(i))
                    else:
                        self.expect(presence is True, "Module {} is not present".format(i))

I am seeing some issue with the above logic.
In our testbed where we share a physical chassis that uses the same Supervisor card but group different LCs for different "logical chassis" so for some "logical chassis" some LCs are added to "skip_mod_list" as they are not meant to be tested for that logical chassis.  Our expectation is that if it is marked as skipped, it is not meant for testing and no state of those skipped modules should be used for any validation logic.   We should always trust what the inventory marked as skipped and not try to look at whatever state the "skipped module" should be.