Adds PowerControl class and integrates power control data

[nicolamos]

Referring to issue #171, I provide a patch for this.

• New class PowerControl
• Filling the fields in the get_single_chassi_power function, similarly to PowerSupply.

I got a bit confused about how to deal with dict subelements which get rendered as strings (but they are not valid JSON because of quoting issues).

In particular, I am referring to the following elements in PowerControl.

   "PowerLimit": {
      "CorrectionInMs": 0,
      "LimitException": "HardPowerOff",
      "LimitInWatts": 32767
    },
    "PowerMetrics": {
      "AverageConsumedWatts": 102,
      "IntervalInMin": 1,
      "MaxConsumedWatts": 113,
      "MinConsumedWatts": 93
    }

[bb-Ricardo]

Wow, fantastic. I'll have a look in the next days. Thank you for putting in the work ⭐️

[nicolamos]

I also added special case for Supermicro PSU models which do not provide the power capacity through Redfish API.
I don’t know if this is good idea to keep the information here or should be dealt with downstream in applications.

[nicolamos]

Added fallback for vendor identification.
Some Supermicro models apparently do not provide Oem nor Vendor information at root level. So we can grab the Manufacturer field from the Chassis.
This means early query Chassis in vendor discovery, before the full system discover has been performed.

[bb-Ricardo]

I would say, this would fit petter into classes/vendor.py

[nicolamos]

Yes, it makes sense, of course. Would using config files/external resources useful here to handle this kind of data?

[bb-Ricardo]

the None in the end could be removed as it is the default.

[bb-Ricardo]

this could probably be compacted to:

vendor_string = grab(self.get_system_properties, "chassis.0.Manufacturer")

[nicolamos]

The problem here is that we don’t have the chassis data at this point. We have to fetch it from Redfish first.
So I have updated the code to be more concise using grab, but still we have to call the GET first. Or am I missing something?