commit c1a75ebc267a78853fb26a3da8c6b3388e6ee07c
author rohitpai <rohitpai77@gmail.com> Fri Jan 03 19:13:36 2025 +0530
committer Ed Tanous <ed@tanous.net> Thu Apr 03 15:26:31 2025 +0000
tree a27f3952e709f94899ac0860fc016df8e1d36439
parent 81f915bc39a97a38b610a461394a795cb49c3f6d

OEM Route Handling Infrastructure

Goal of the MR is to provide infrastructure support in bmcweb to manage
the OEM fragment handling separately. OEM schema are vendor defined and
per DMTF resource we could have multiple vendor defined OEM schema to be
enabled.

The feature allows registration of route handler per schema per OEM
namespace.
Example
```
REDFISH_SUB_ROUTE<"/redfish/v1/Managers/<str>/#/Oem/OpenBmc">(service,
 HttpVerb::Get)(oemOpenBmcCallback);
REDFISH_SUB_ROUTE<"/redfish/v1/Managers/<str>/#/Oem/Nvidia">(service,
 HttpVerb::Get)(oemNidiaCallback);
```

We can have separate vendor defined route handlers per resource. Each of
these route handlers can populate their own vendor specific OEM data.
The OEM code can be better organized and enabled/disabled as per the
platform needs. The current MR has the code changes related to handling
GET requests alone. The feature only supports requests
where the response payload is JSON.

Tests
- All UT cases passes
- New UT added for RF OEM router passes
- Service Validator passes on qemu
- GET Response on Manager/bmc resource contains the OEM fragment

```
curl -c cjar -b cjar -k -X GET https://127.0.0.1:2443/redfish/v1/Managers/bmc
{
  "@odata.id": "/redfish/v1/Managers/bmc",
  "@odata.type": "#Manager.v1_14_0.Manager",

  "Oem": {
    "OpenBmc": {
      "@odata.id": "/redfish/v1/Managers/bmc#/Oem/OpenBmc",
      "@odata.type": "#OpenBMCManager.v1_0_0.Manager",
      "Certificates": {
        "@odata.id": "/redfish/v1/Managers/bmc/Truststore/Certificates"
      }
    }
  },

  "UUID": "40575e98-90d7-4c10-9eb5-8d8a7156c9b9"
}
```

Change-Id: Ic82aa5fe760eda31e2792fbdfb6884ac3ea613dc
Signed-off-by: Rohit PAI <rohitpai77@gmail.com>