feat: implement Redfish API v1 Systems and FirmwareInventory endpoints

[nmgaston]

Adds complete DMTF Redfish v1.0.0 compliance with FirmwareInventory endpoints for Intel AMT device management.

• FirmwareInventory API: SoftwareInventory v1.3.0 endpoints with multi-source firmware support and BIOS parsing
• Comprehensive Tests: 2,064 lines of unit tests with GoMock integration and parallel execution
• Production Features: HTTP caching with ETag generation, type-safe error handling, and Intel OEM extensions

[rsdmike]

Hey @nmgaston, looking good so far. Couple questions:

1. Are we planning to keep the base /api part for redfish? when you click on the odata.ids in postman for example, none of them work because they dont have that /api prefix. Example:

{
    "@odata.id": "/redfish/v1/Systems",
    "@odata.type": "#ComputerSystemCollection.ComputerSystemCollection",
    "Members": [
        {
            "@odata.id": "/redfish/v1/Systems/744025c9-df9d-4766-9424-213a7517e6c0" <--hyperlink here doesnt work
        }
    ],
    "Members@odata.count": 1,
    "Name": "Computer System Collection"
}

2. Running the validator, im having trouble getting the auth to work, i have tried:
   python RedfishServiceValidator.py --authtype Token --token <token>-r http://<host>/api
   and
   python RedfishServiceValidator.py -u <username> -p <password> -r http://<host>/api
   I get 401s for both of those, (not including the /api causes 404 not founds).

3. Re: Architecture - I know i did everything in the same file for the POC, but eventually want to follow same architecture as the rest of the app - breaking out the http portion from the parsing/logic and putting that in the business layer. Additionally, If we're thinking long term maintainability -- i dont know that leveraging reflection is gonna be the best way forward, ideally we type what we can or leverage existing go modules that might already have types for redfish. For now, I think we make a conscious decision that we're good for a POC as is, but come time to merge this to the main repo, I think these are the two main things that would need to get addressed before that happens and gets officially released.

[nmgaston]

1. Are we planning to keep the base /api part for redfish? when you click on the odata.ids in postman for example, none of them work because they dont have that /api prefix. Example:

@rsdmike Yes, I have a PR to change this since it will make working with the tools much easier: #16

[nmgaston]

2. Running the validator, im having trouble getting the auth to work, i have tried:
python RedfishServiceValidator.py --authtype Token --token <token>-r http://<host>/api
and
python RedfishServiceValidator.py -u <username> -p <password> -r http://<host>/api
I get 401s for both of those, (not including the /api causes 404 not founds).

@rsdmike - We don't have authorization done yet that will work with the tools. We've had to turn off the authentication and authorization. The steps are outlined here: https://jira.devtools.intel.com/browse/CM-32, but I'll add them below too.

1. In order to test without authorization, set the following value in the config.yml -> auth: disabled -> true
2. Start up your console service
3. Run Service Validator:

cd /home/nat/git/Redfish-Service-Validator && python3 RedfishServiceValidator.py
-i http://localhost:8181/api/redfish/v1/
--forceauth
--debugging
--logdir ./validation_logs
-v

4. HTML file with endpoint status can be found in the ./validation_logs directory

[nmgaston]

3. Re: Architecture - I know i did everything in the same file for the POC, but eventually want to follow same architecture as the rest of the app - breaking out the http portion from the parsing/logic and putting that in the business layer. Additionally, If we're thinking long term maintainability -- i dont know that leveraging reflection is gonna be the best way forward, ideally we type what we can or leverage existing go modules that might already have types for redfish. For now, I think we make a conscious decision that we're good for a POC as is, but come time to merge this to the main repo, I think these are the two main things that would need to get addressed before that happens and gets officially released.

@rsdmike - Makes sense. We can do a refactor after we get this main development done and before merging it into main.